To naturally represent following kind of relationship in Ruby code, I
think, if we can degrade a class to a module, it will be posssible.
For example, we have a Person class, a Man class ,and a Teacher class.
Man inherits from Person. And a Man object may also act as a teacher
ã??Usually, we can implement this relationship as follows:
class Person
end
class Teacher
end
class Man < Person
set_teacher(a_teacher)
@teacher = a_teacher
end
end
In this implementation, a Man object is a delegator to a Teacher object.
To call Teacher methods from a Man object , we need lots of delegate
method. Itâ??s unconvenient.
But how about if Ruby provide a degradation mechanism, then we can
degrade a class to a module, then we can include the degraded class into
another class. The code will become as follows:
class Person
end
class Teacher
end
degrade_to_module Teacher # or something else, this is imagined by me
.
class Man < Person
include Teacher
end
Or something like this
class Person
end
class Teacher
end
degrade_to_module Teacher # or something else, this is imagined by me
.
Class Man < Person
End
M = Man.new
m.externd(Teacher)
Dose this make sense? Thanks.
Best regards
uncutstone
end
You could always:
class Person; end
module Teacher; end
class Man < Person
include Teacher
end
So why is it that you need to have Teacher as a class?
Really, though, I think the best solution would be to do either of the
following:
class Person; end
class Man < Person; end
class Teacher < Man; end
or
class Person; end
module Teacher; end
other modules of things that a Man could be
class Man < Person; include Teacher; end
M.T.
Uncutstone Wu wrote:
But how about if Ruby provide a degradation mechanism, then we can
degrade a class to a module, then we can include the degraded class into
another class. The code will become as follows:
Sounds kind of like you want a state pattern. Man is always a Person,
but only sometimes is a Teacher. So when Man is in the “Teacher state”,
it has all the Teacher methods. Yes, you need some
deligation/biolerplate code, but I think that is because the
relationship is not as easy as you imagine. For example, is every
Teacher a Man, or might some be a Woman? But if some Woman classes are
already inheriting from Teacher, how will the modularization effect
them? That’s probably not a very clear example, but I think that the
relationship is not so easy to define since it is not a 1-to-1 map of
All A are B, but rathetr Some A are B, and some C are B, but no A are
C. Something like that anyhow. Just ignore me if I make no sense. 
Regards,
Jordan
Uncutstone Wu wrote:
… As you said, a man is not always a teacher. So, rather than including Teacher
into class Man, it’s better to extend a Man object individually as in the following code.
…
Thanks.
uncutstone
… or you could (somewhat the other way round) have a module Teacher
that makes a thread_local method available; this way you also could
dynamically modify class Man!
http://rubylution.ping.de/articles/2006/05/02/thread-local-variables
I know the example code is not very accurate. Acctually, the last
snippet of code make more sense. As you said, a man is not always a
teacher. So, rather than including Teacher into class Man, it’s better
to extend a Man object individually as in the following code.
class Person
end
class Teacher
end
degrade_to_module Teacher # or something else, this is imagined by me
.
Class Man < Person
End
a_man = Man.new
a_man.externd(Teacher)
But what I want to said acctually is not relative to these three class.
You can just replace them as class A,B,and C. I think you may recognize
that you have ever encounter this kind of modeling problems.
To some extent, it’s relative to role modeling,for example, a man may
play a teacher role. You can always use a delegator to implement a role.
But I think if you can directly mix a degraded class into a object, the
code will be more concise( you don’t need write delegate methods),and
the design will be clearer.
Thanks.
uncutstone
Verno Miller wrote:
Uncutstone Wu wrote:
… As you said, a man is not always a teacher. So, rather than including Teacher
into class Man, it’s better to extend a Man object individually as in the following code.
But if I want Teacher to be a class at some other occasions,and sometime
I want it to be module so that it could be able to be mixed into other
objects.
Best regards.
On Mon, 18 Sep 2006 19:31:20 +0900, Uncutstone Wu wrote:
Best regards.
class Person; end
class Man < Person; end
module TeacherModule; end
class Teacher; include TeacherModule; end
then you can include TeacherModule into any Man objects you want, and if
you define all of your Teacher methods on the TeacherModule, then they
will automatically appear in the teacher class.
If you still want to look at delegates, have a look at the standard
Delegator and Forwardable libraries.
Sadly, I lack more information to tell you whether there’s something
even
more clever you can do by taking advantage of duck typing.
–Ken
Here, you can ditch classes altogether:
class Module
def new(*args, &blk)
mod = self
klass = Class.new { include mod }
const_set( “#{name}Class”, klass )
klass.new(*args, &blk)
end
end
Note, this is just off the top of my head so don’t expect it to work
“out-of-the-box” but you get the idea.
This would be a perfect solution except but there is one limitation:
the aweful Dynamic Module Inclusion Problem.
T.
Trans wrote:
Here, you can ditch classes altogether:
class Module
def new(*args, &blk)
mod = self
klass = Class.new { include mod }
const_set( “#{name}Class”, klass )
klass.new(*args, &blk)
end
end
…
T.
Cool, Trans. Reminds me a bit of a snippet that adds virtual methods to
Ruby.
Thanks for all your replies. they really help.