mixins etc.

[Alexandru Popescu ☀]

On Wed, Apr 9, 2008 at 1:24 PM, 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
>

Both mixins and traits are becoming part of the hierarchy chain, so I
think this may be the only way to achieve it when mixins/traits are
applied dynamically at runtime (indeed in case we are interested in
the full theoretical concept).


>  bye blackdrag
>
>  --
>  Jochen "blackdrag" Theodorou
>  The Groovy Project Tech Lead (http://groovy.codehaus.org)
>  http://blackdragsview.blogspot.com/
>
>

[Alexandru Popescu ☀]

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
>

[Graeme Rocher-2]

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

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

[Jochen Theodorou]

Alexandru Popescu ☀ schrieb:
[...]
> Both mixins and traits are becoming part of the hierarchy chain, so I
> think this may be the only way to achieve it when mixins/traits are
> applied dynamically at runtime (indeed in case we are interested in
> the full theoretical concept).

Java itself has no real concept of multiple inheritance besides
interfaces. Given that this comes not for free, may I ask what we need
this for? I still do not see why this is really needed. Also the
MetaClass could be asked directly for such things... it would be easy to
add that (and breaking the interface again)

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-2]

On Wed, Apr 9, 2008 at 12:10 PM, Jochen Theodorou <blackdrag@...> wrote:

> Alexandru Popescu ☀ schrieb:
>  [...]
>
>
> > Both mixins and traits are becoming part of the hierarchy chain, so I
> > think this may be the only way to achieve it when mixins/traits are
> > applied dynamically at runtime (indeed in case we are interested in
> > the full theoretical concept).
> >
>
>  Java itself has no real concept of multiple inheritance besides interfaces.
> Given that this comes not for free, may I ask what we need this for? I still
> do not see why this is really needed. Also the MetaClass could be asked
> directly for such things... it would be easy to add that (and breaking the
> interface again)

The only real feature of traits I see over mixins if we go with my
definition of mixins being runtime/non-hierarchy effecting and traits
being compile time/hierarchy effecting  is that you get the features
of type inference that you see in Scala which will result in better
IDE support and easier integration on the Java side which doesn't see
dynamic methods.

However, whether we *need* traits is another issue. Mixins I'm
certainly up for and was one of the things I hoped to implement for
1.6, thankfully Alex has nearly done the job for me :-)

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

[Alexandru Popescu ☀]

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
>

[Graeme Rocher-2]

On Wed, Apr 9, 2008 at 12:19 PM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:

>
> 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?

I haven't tried, but for sure let us know if you do :-)

The main purpose of my post here was to try and differentiate what a
mixin and a trait is because in my view they're different concepts

Cheers

>
>
>
>  ./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
>  >
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

[Jochen Theodorou]

Graeme Rocher schrieb:
[...]
> The main purpose of my post here was to try and differentiate what a
> mixin and a trait is because in my view they're different concepts

according to the wiki article Alexandru linked mixins are affecting the
heirarchy.

Anyway, this won't lead to anything. Let us make a matrix consisting of
heirarchy affecting or not and being a runtime or compile time
construct. Further let us not give names to these, but think what we
want to use it for. Groovy is a pragmatic language and as such we don't
want to adapt a concept of another programming language just for the
name of it. there must be a usage for this and the usage should be the
primary focus here.. I mean... why adding a useless concept? If we then
have defined this and agreed to implement it, then we should think about
a name

As for the definitions... I haven't ever seen a formal and general
definition of either traits or mixins. For example it is said that Ruby
modules are like traits... I am sure the modules are no compile time
construct. About 3 years ago or so I tried to discuss the difference
with a few people (not on this list), but got no real result. It is
simply too unclear and different from language to language.

The only language I know implementing Traits is Scala and there it is
done to simulate multiple inheritance. Seems like the idea was to give a
portion of Ruby mixins and Java interface in a bottle and shake it. As
Scala is a static language traits are of course a compile time construct
there... but that does not mean it has to be in Groovy such a construct too.

As you can see in http://www.scala-lang.org/intro/mixin.html Scala has
also mixins but these are really traits. Maybe
http://www.cs.utah.edu/plt/publications/aplas06-fff.pdf is of interest
as well... surely scheme is not known to be a compile time language. The
first definition I can find is
http://www.iam.unibe.ch/~scg/Research/Traits/ and there it says nothing
about compile or runtime, but it tells that the hierarchy is not changed
by traits... If anything, then I would say our categories and DGM and
this Alex' mixins are traits then. At last if you take "affects the
hierarchy" as key.

But as I said... let us first look at what we want, what we have and how
we want to use it before giving it real names

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-2]

On Wed, Apr 9, 2008 at 1:13 PM, Jochen Theodorou <blackdrag@...> wrote:

> Graeme Rocher schrieb:
>  [...]
>
>
> > The main purpose of my post here was to try and differentiate what a
> > mixin and a trait is because in my view they're different concepts
> >
>
>  according to the wiki article Alexandru linked mixins are affecting the
> heirarchy.
>
>  Anyway, this won't lead to anything. Let us make a matrix consisting of
> heirarchy affecting or not and being a runtime or compile time construct.
> Further let us not give names to these, but think what we want to use it
> for. Groovy is a pragmatic language and as such we don't want to adapt a
> concept of another programming language just for the name of it. there must
> be a usage for this and the usage should be the primary focus here.. I
> mean... why adding a useless concept? If we then have defined this and
> agreed to implement it, then we should think about a name
>
>  As for the definitions... I haven't ever seen a formal and general
> definition of either traits or mixins. For example it is said that Ruby
> modules are like traits... I am sure the modules are no compile time
> construct. About 3 years ago or so I tried to discuss the difference with a
> few people (not on this list), but got no real result. It is simply too
> unclear and different from language to language.
>
>  The only language I know implementing Traits is Scala and there it is done
> to simulate multiple inheritance. Seems like the idea was to give a portion
> of Ruby mixins and Java interface in a bottle and shake it. As Scala is a
> static language traits are of course a compile time construct there... but
> that does not mean it has to be in Groovy such a construct too.
>
>  As you can see in http://www.scala-lang.org/intro/mixin.html Scala has also
> mixins but these are really traits. Maybe
> http://www.cs.utah.edu/plt/publications/aplas06-fff.pdf is of interest as
> well... surely scheme is not known to be a compile time language. The first
> definition I can find is http://www.iam.unibe.ch/~scg/Research/Traits/ and
> there it says nothing about compile or runtime, but it tells that the
> hierarchy is not changed by traits... If anything, then I would say our
> categories and DGM and this Alex' mixins are traits then. At last if you
> take "affects the hierarchy" as key.
>
>  But as I said... let us first look at what we want, what we have and how we
> want to use it before giving it real names

+1 great write-up Jochen.

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

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Graeme Rocher schrieb:
[...]
> +1 great write-up Jochen.

thx, let me try another writeup

let us say R stays for runtime and C for compile time, H for affecting
the hierarchy, N for not affecting the hierarchy, then we get four
possible variations (CN, CH, RN, RH) and I will try to imagine some
scenarios and which form they would fit. Ah yes... since I need to name
it somehow to address it in general, I will for now call such a
mixin/trait/whatever class toolbox.

(S1) The user has a set of methods he wants to apply to different
classes with implementing these methods only in the "toolbox" -> CN, CH,
RN, RH

Since all of them will do this Job let us refine the scene... Let us say
(S2) The class is a Java class and we want to add methods to be able to
call them later -> RN, probably RH

(S3) A user wants to know if our toolbox got applied to a certain class
-> no restrictions, it could be done via a special instanceof or with a
MetaClass method. If a instanceof from Java should work here, then CH

(S4) The class contains an abstract method form the super class and our
tool box should be used to implement this method -> CN, CH

(S5) The toolbox implements a certain interface and the class should
then implement this too -> RH,CH, in combination with the one before CH only

(S6) The user does not want that his toolbox gets influenced by another
toolbox. Id he wants to control that at source level -> CH, CN. If
controlled at runtime -> RH, RN

(S7) The user wants that an exception is thrown when he wnats to apply
his tools box, but this would redefine a method from another toolbox ->
RH, RN

(S8)The user wants to limit the "visibility" of his toolbox.
(S8a) per Thread -> none of these
(S8b) per class and subclasses -> all
(S8c) per package -> none

Maybe others can add usages and scenarios.... Anyway only S2 speaks for
a runtime construct atm... and that is more or less what a category
would do. A category would also cover S8a, while the proposed construct
seems to be addressing more S8b, but the difference is not very big,
since categories do also address S8b a bit.

I personally favor CH I must say, because the idea of being able to have
an automated implementation of interfaces and maybe AST transformations
is something I like.

then there are open questions, especially with the form without the
"self" reference.

(Q1) what happens to a private method in the toolbox?
(Q2) how to call the original method?
(Q3) can I maintain a static state in the toolbox?
(Q4) can I maintain a non static state in the toolbox?
(Q5) How will a closure resolve its methods/properties when in the toolbox?
(Q6) is the toolbox getProperty/setProperty/invokeMethod/missingMethod
method overwriting the one in the class th toolbox is applied to?
(Q7) can a toolbox provide a constructor?
(Q8) can a toolbox provide a static property/field
(Q9) can a toolbox provide a non static property/field
(Q10) is a private field in the toolbox also a field in the class the
toolbox is applied to?

Well, this is all I can think of within 5 minutes ;)

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

[Dierk König]

| Java itself has no real concept of multiple inheritance
| besides interfaces.

... and static imports for a very limited support for
the 'static' part of the story...


cheers
Dierk

[Russel Winder-4]

On Wed, 2008-04-09 at 14:13 +0200, Jochen Theodorou wrote:

> The only language I know implementing Traits is Scala and there it is
> done to simulate multiple inheritance. Seems like the idea was to give a

C++ has an awful lot of traits in its standard library -- just because a
language doesn't have a keyword traits doesn't mean it doesn't implement
them !

And don't forget that the new C++ standard will have threads and lambda
functions, not to mention type inferencing and concepts (aka template
parameter types) :-)

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone], [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]