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

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

:smiley:

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

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.

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

Thanks for all your replies. they really help.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs