From: intc_ctor@... (Phil Tomson)
Date: 2004-02-17T07:39:54+09:00
Subject: Re: OT: Traits

"Robert Klemme" <bob.news@gmx.net> wrote in message news:<c0q8nb$19imk0$1@ID-52924.news.uni-berlin.de>...
> "Daniel Berger" <djberg96@hotmail.com> schrieb im Newsbeitrag
> news:6e613a32.0402140823.6e549b24@posting.google.com...
> > matz@ruby-lang.org (Yukihiro Matsumoto) wrote in message
>  news:<1076736977.263683.27564.nullmailer@picachu.netlab.jp>...
> > > Hi,
> > >
> > > 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 <module> or unextend <module>
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 <methname> 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