A idea about Ruby module, can we degrade a class to a module

[Uncutstone Wu]

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

 

[Matt Todd]

class Person

end

class Teacher
end

class Man < Person
set_teacher(a_teacher)
@teacher = a_teacher
end
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.

 

[MonkeeSage]

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]

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

 

[Verno Miller]

... 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

 

[Uncutstone Wu]

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.

 

[Ken Bloom]

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.

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

 

[Trans]

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.

 

[Verno Miller]

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.

http://bigbold.com/snippets/posts/show/2621

 

[uncutstone]

Thanks for all your replies. they really help.