>
> 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?
.w( the_mindstorm )p.