Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
Regards,
Dan
PS - Sorry if this is a double post. Emails sent from my home and
work account don’t appear to be making it to the list. This was
posted via Google Groups.
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
“module” in Ruby and “trait” are very similar idea.
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
OGI is in my neighborhood.
I found this interesting quote on the first page:
“Despite the passage of nearly twenty years, neither multiple inheritance
nor mixins have acheived wide acceptance”
Well, I can see why multiple inheritance has fallen out of favor, but I
use mixins all the time.
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
I’ve just done a writeup of Traits in Ruby on my blog
(http://homepages.ihug.com.au/~naseby/33.html). I think, in summary, that
traits are a solution to a problem that may cause more problems, if
implemented in a language without a good browsing IDE (ie, pretty much
anything except Smalltak). I like the finer grained composition in theory
for its flexibility, and I like the level of library support that a traits
implementation can provide over and above straight Ruby modules. But its
probably not worth the trouble…
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
“module” in Ruby and “trait” are very similar idea.
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
“module” in Ruby and “trait” are very similar idea.
matz.
Yes, I thought so, too. Their argument against mixins boiled down to
“What if you have identical methods in two different modules that you
wish to ‘include’?”. But, so far that just hasn’t happened in my
personal experience.
Dan
···
In message “OT: Traits” > on 04/02/14, Daniel Berger djberg96@hotmail.com writes:
Since I haven’t seen a full discussion on the topic, I thought I would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
Since I haven’t seen a full discussion on the topic, I thought I
would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
Since I haven’t seen a full discussion on the topic, I thought I
would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
“module” in Ruby and “trait” are very similar idea.
matz.
Yes, I thought so, too. Their argument against mixins boiled down to
“What if you have identical methods in two different modules that you
wish to ‘include’?”. But, so far that just hasn’t happened in my
personal experience.
The problem that I see is with using Modules is when traits have to be
exchanged during the life time of an instance. At least I didn’t manage
to include a Module and de-include if afterwards. Or does simply
“overriding” by including another module with similar methods solve the
problem?
Kind regards
robert
···
In message “OT: Traits” > > on 04/02/14, Daniel Berger djberg96@hotmail.com writes:
Since I haven’t seen a full discussion on the topic, I thought I
would
see what Ruby programmers think of “traits” as an OO concept. Cool
idea? Or a solution in need of a problem?
“module” in Ruby and “trait” are very similar idea.
matz.
Yes, I thought so, too. Their argument against mixins boiled down to
“What if you have identical methods in two different modules that you
wish to ‘include’?”. But, so far that just hasn’t happened in my
personal experience.
The problem that I see is with using Modules is when traits have to be
exchanged during the life time of an instance. At least I didn’t manage
to include a Module and de-include if afterwards.
It has been brought up a few times here in the past:
Sometimes you want an object’s role to change so it would be nice if
there were some sort of uninclude or unextend
methods.
In the meantime, it probably wouldn’t be too hard to ‘roll your own’
uninclude. Just get the list of instance methods from the module and
undef_method in the class. Something like:
class Module
def uninclude(mod)
mod.instance_methods.each {|meth|
undef_method meth
}
end
end
…I’m still figuring out how to do unextend (which is arguably more
useful than uninclude).
Phil
···
In message “OT: Traits” > > > on 04/02/14, Daniel Berger djberg96@hotmail.com writes:
It has been brought up a few times here in the past:
Sometimes you want an object’s role to change so it would be nice if
there were some sort of uninclude or unextend
methods.
In the meantime, it probably wouldn’t be too hard to ‘roll your own’
uninclude. Just get the list of instance methods from the module and
undef_method in the class. Something like:
class Module
def uninclude(mod)
mod.instance_methods.each {|meth|
undef_method meth
}
end
end
…I’m still figuring out how to do unextend (which is arguably more
useful than uninclude).
Maybe something like:
class Object
def unextend(mod)
(class << self; self; end) .class_eval <<-EOE
mod.instance_methods.each {|meth| undef_method(meth) }
EOE
end
end