« Return to Thread: mixins etc.

Re: mixins etc.

by Alexandru Popescu ☀ :: Rate this Message:

Reply to Author | View in Thread

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

>  Cheers
>
> >
>  >  bye blackdrag
>  >
>  >  --
>  >  Jochen "blackdrag" Theodorou
>  >  The Groovy Project Tech Lead (http://groovy.codehaus.org)
>  >  http://blackdragsview.blogspot.com/
>  >
>  >
>  >  http://www.g2one.com/
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe from this list, please visit:
>  >
>  >    http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>
>
>
>  --
>
>
> Graeme Rocher
>  Grails Project Lead
>  G2One, Inc. Chief Technology Officer
>  http://www.g2one.com
>

 « Return to Thread: mixins etc.

LightInTheBox - Buy quality products at wholesale price