Re: mixins etc.

>
> On Wed, Apr 9, 2008 at 2:00 PM, Graeme Rocher <graeme@...> wrote:
>  >
>  > On Wed, Apr 9, 2008 at 11:48 AM, Alexandru Popescu ☀
>  >  <the.mindstorm.mailinglist@...> wrote:
>  >  >
>  >  > 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)
>  >
>  >  I'm never convinced by things I read on wikipedia :-)
>  >
>  >   For one have you actually tried other language implementations of
>  >  mixins. For example this Ruby code:
>  >
>  >  ------------------------------------------------------------------------
>  >  # Convert a integer value to English.
>  >  module Stringify
>  >   # Requires an instance variable @value
>  >   def stringify
>  >     if @value == 1
>  >       "One"
>  >     elsif @value == 2
>  >       "Two"
>  >     elsif @value == 3
>  >       "Three"
>  >     end
>  >   end
>  >  end
>  >
>  >  # A Math module akin to Java Math class.
>  >  module Math
>  >   # Could be called as a class, static, method
>  >   def add(val_one, val_two)
>  >     BigInteger.new(val_one + val_two)
>  >   end
>  >  end
>  >  # Base Number class
>  >  class Number
>  >   def intValue
>  >     @value
>  >   end
>  >  end
>  >
>  >  # BigInteger extends Number
>  >  class BigInteger < Number
>  >
>  >   # Add instance methods from Stringify
>  >   include Stringify
>  >
>  >   # Add class methods from Math
>  >   extend Math
>  >
>  >   # Add a constructor with one parameter
>  >   def initialize(value)
>  >     @value = value
>  >   end
>  >  end
>  >
>  >  bigint1 = BigInteger.new(10)
>  >
>  >  puts  bigint1.instance_of?(Math.class)
>  >  puts  bigint1.kind_of?(Math.class)
>  >  puts  bigint1.instance_of?(Stringify.class)
>  >  puts  bigint1.kind_of?(Stringify.class)
>  >  ------------------------------------------------------------------------------------------
>  >
>  >  Here it prints
>  >
>  >  false
>  >  false
>  >  false
>  >  false
>  >
>  >  So unless I'm rubbish at Ruby (which is quite possible) then I don't
>  >  see Ruby mixins effecting the object heirarchy
>  >
>
>  Oops... I wasn't aware that the discussion is about implementing Ruby
>  mixins. What about the other languages implementing this concept?

>
>
>
>  ./alex
>  --
>  .w( the_mindstorm )p.
>   Alexandru Popescu
>
>
>  >  Cheers
>  >
>  >
>  >
>  >  >
>  >  >
>  >  >  ./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
>  >  >  >
>  >  >
>  >
>  >
>  >
>  >  --
>  >
>  >
>  > Graeme Rocher
>  >  Grails Project Lead
>  >  G2One, Inc. Chief Technology Officer
>  >  http://www.g2one.com
>  >
>