On Wed, Apr 9, 2008 at 1:36 PM, Graeme Rocher <
graeme@...> wrote:
>
> On Wed, Apr 9, 2008 at 11:24 AM, Jochen Theodorou <
blackdrag@...> wrote:
> > Alexandru Popescu ☀ schrieb:
> >
> >
> > > On Wed, Apr 9, 2008 at 11:55 AM, Graeme Rocher <
graeme@...> wrote:
> > >
> > > > Traits and mixins are different concepts, one is compile time the
> > > > other is dynamic and runtime.
> > > >
> > > > This still needs to be implemented for mixins, but trait supported
> > > > would be cool none the less :-)
> > > >
> > > > Cheers
> > > >
> > > >
> > > >
> > >
> > > I may be a bit late to the party and my comments my sound a bit
> > > negative, so I'll apologize for them upfront. I have passed through
> > > this thread (and the older one) and here are my observations:
> > >
> > > 1/ this looks like an enhanced DGM mechanism under a new name. I do
> > > think that allowing enhancing DGM (by additions/overloading etc) is a
> > > powerful feature Groovy should support I don't think a new name should
> > > be introduce for that.
> > >
> >
> > but neither DGM nor categories are good names for that.
> >
> >
> >
> > > 2/ traits and mixins are 2 similar but different concepts. Traits are
> > > affecting the stateless functionality, while mixins are able to
> > > enhance functionality by bringing state. Also, both concepts (at least
> > > in theory) are influencing the hierarchy chain. Both mechanism are
> > > usually applied at runtime (indeed they can also be applied at
> > > "compile" time but this is less powerful). As I presented in an older
> > > post, as long as instanceof and Class.isAssignableFrom cannot be
> > > overwriten then it will be quite difficult to support runtime
> > > traits/mixins
> > >
> >
> > can you please again give an example? I can't remember why this is needed
> > for traits/mixins
>
> I can see this being the case for traits, but for mixins I don't think
> this is accurate. A mixin is not a is a relationship and that is what
> instanceof and isAssignableFrom imply. A trait in my view is different
> as it very much involves types and the type heirarchy, but Alex's
> solution is for mixins not traits (that is a different path)
>
> My view is the mixin solution here is good in concept, and not adding
> any complexity, my main problem with it is as I said before the usage
> of self as a first argument and the lack of support for static vs
> instance methods
>
Right, I think there may be more than one definition of this concept
(starting with the "theoretical" one -- the one I am using and which
can be found on [1], and those that got implemented in various
languages)
./alex
--
.w( the_mindstorm )p.
Alexandru Popescu
[1]
http://en.wikipedia.org/wiki/Mixin