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]

[Jochen Theodorou]

Russel Winder schrieb:
> 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 !

C++ has multiple inheritance, so there is no need for traits to simulate
that ;) Since the concept itself is not clear it is difficult to discuss
when something is a trait and when not.

> 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) :-)

hehe.

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

[Robert O'Connor]

nice write up!
Jochen Theodorou 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
>
> bye blackdrag
>

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

    http://xircles.codehaus.org/manage_email

[Peter Niederwieser]

Alexandru Popescu ☀ wrote:

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.

Exactly my thoughts.

Alexandru Popescu ☀ wrote:

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

I'm not sure whether there is a globally agreed-upon definition of traits vs. mixins. For example, Scala's traits are stateful, and you can mix them both into classes and objects (at object creation time). If Scala can do "real" traits/mixins, Groovy can too!

Alexandru Popescu ☀ wrote:

Last, but not least, I would like to emphasize that my comments are
not meant to criticize Alex's work which is highly appreciated, but
rather to express that I am worried by the fact that Groovy will
increase its complexness.

+1

Cheers,
Peter

[Peter Niederwieser]

Looks more like "DGM for the rest of us" or C# extension methods to me. Isn't this concept a lot less powerful than mixins in other languages? E.g. it's not stateful, and also it's strongly coupled to the classes that it "extends" and therefore not reusable. Just my 2 cents.

Cheers,
Peter

Alex Tkachman wrote:

After discussion in the list I am ready to commit first draft of
mixins implementation. This work is side result of some internal
refactorings in meta class implementation and can easily be switched
off. The reason I want it to be in the trunk is to give people chance
to play with it and find what is good and what is bad in the approach
and implementation.

So what is mixin?

Mixin is usual category-like class, which provides methods to extend
some (or several) existing classes.

class ArrayListExt {
   static def newArrayListMethod (ArrayList self) {
        "result of newArrayListMethod "
   }
}

simple use of it

ArrayList.mixin ArrayListExt

and now you can use

assertEquals "result of newArrayListMethod ", [].newArrayListMethod ()

Of course, you can mix class with several other classes at the same time

ArrayList.mixin ArrayListExt, ListExt, CollectionExt

For groovy obejcts where is even nicer compile time way to achieve
almost the same

@Mixin(MyClassExt)
class MyClass {
     def result () {
         longRunningJavaMethod ()
     }
}

and write for example in Java

public MyClassExt {
         public static Set<Collection> longRunningJavaMethod (MyClass
self) { /// }
}

In fact @Mixin in implemented with help of Class.mixin method. Thanks
for wonderful AST transformations call to this method added in to
static initialization of the class.

You can wonder here why don't create methods for mixins in compile
time. It is perfectly doable. Just don't implemented. We need to think
does it make sense or not.

Another nice feature for groovy objects is ability to do per instance mixins

def  groovyObject = new MyClass ()
groovyObject.mixin MyClassExt
groovyObject.longRunningJavaMethod () // will work only for this
particualr instance

How does it work?

To understand how all that works we need to remember how our MOP
selects methods. We have four layers. Each of these overrides previous
one.

1) Methods of the class and super classes (including all their
modifications except categories)
2) DGM methods
3)
4) EMC methods
5) methods of categories in use

As you noticed I said "four layers" but mentioned five and left 3)
blank. The reason is it is exactly the place which mixin methods take.
They go to the same method index as original methods and DGM. Any EMC
methods and categories applied on top of that.

So what happen when you add mixins in to the class is recreation of
meta class. So far we able to recreate meta classes for MetaClassImpl
and ExpandoMetaClass, otherwise runtime exception is thrown.

It is important to note that when we apply mixin to class dynamically
(not on compilation time or in static initializer) it might happen
that meta classes already created for some derived classes and will
not be effected. EMC does special and complicated tricks to handle
missing methods by checking super classes. I don't do the same for
mixins right now. I think in the future we can easily get rid of that
and combines mixin and EMC methods in the same layer and just
automatically recreate meta classes. Fortunately now it is relatively
cheap operation compare to the very expensive past.

Please play with trunk and comment. If we finally decide to switch it
off it will be very easy.

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Peter Niederwieser schrieb:
> Looks more like "DGM for the rest of us" or C# extension methods to me. Isn't
> this concept a lot less powerful than mixins in other languages? E.g. it's
> not stateful, and also it's strongly coupled to the classes that it
> "extends" and therefore not reusable. Just my 2 cents.

I think making those "mixins" stateful wouldn't be much of a problem
anymore. Also true, they are coupled to the class they "extend", but
since there is only one class at a time we apply them to, there is no
reason to not to extend "Object". They also have not the same method
overwriting rules as DGM or categories, so I think that you can have a
more general and reusable construct with this. I also think that it
wouldn't be very difficult to add static and non static methods through
such a "mixin"...

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

[Luke Daley]

On 09/04/2008, at 6:42 PM, Graeme Rocher wrote:

> Just to comments on this I personally don't think the implementation
> can be regarded as complete or be something that we can commit to
> until we eliminate the need for the first argument being a reference
> to the object

Could not agree with this more. Until this is possible, it just feels  
like a hack and an addon rather than a first class feature.

It's great to see this getting traction though.

LD.

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

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

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

> Peter Niederwieser schrieb:
>
>
> > Looks more like "DGM for the rest of us" or C# extension methods to me.
> Isn't
> > this concept a lot less powerful than mixins in other languages? E.g. it's
> > not stateful, and also it's strongly coupled to the classes that it
> > "extends" and therefore not reusable. Just my 2 cents.
> >
>
>  I think making those "mixins" stateful wouldn't be much of a problem
> anymore. Also true, they are coupled to the class they "extend", but since
> there is only one class at a time we apply them to, there is no reason to
> not to extend "Object". They also have not the same method overwriting rules
> as DGM or categories, so I think that you can have a more general and
> reusable construct with this. I also think that it wouldn't be very
> difficult to add static and non static methods through such a "mixin"...

This limitation would be completely removed if we eliminated the need
to specify the type as the first argument.

As I said before, at the moment the solution there currently is
incomplete until it is possible to do this

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

[Alex Tkachman]

As I spent some time already prototyping implementation of traits. So
now I feel more comfortable to answer questions. But first of all let
me describe my concept of trait.

- Trait is interface with possible partial implementation
- Trait's implementation is stored in static inner class Trait of
interface with predefined name
- Trait can be implemented both in Java and Groovy. Presence of static
inner class Trait is only indication that the interface is trait.

trait MyTrait {
   def getValue () {
      @myValue
   }
}

class X extends Y implements Z with MyTrait {
   int myValue
}

means

interface MyTrait {
   def getValue ()

  public static class Trait {
   public static def getValue (MyTrait self) {
      self.@myValue
   }
  }
}

class X extends Y implements Z, MyTrait {
   int myValue

   def getValue () {
      MyTrait.Trait.getValue(this)
   }
}

- Trait is compile time, effecting hierarchy and preserving type
information construction. So you can use instanceof

assertTrue new X () instanceof MyTrait

- Trait has no its own state but require derived class to provide
necessary fields/properties
- Trait applied to class enforce addition of all methods not yet
presented in the class and super classes
- Trait applied to class enforce addition of all properties not yet
presented in the class and super classes
- Trait syntax allows to use them for creating mixin definition
(static methods with 1st param)

Q1) what happens to a private method in the toolbox?

My idea is that only methods without modifiers becomes methods of
interface. Any implemented methods becomes members of trait
implementation and any static implemented methods becomes static
methods of Trait

trait MyTrait {
   def getValue () {
      getDoubleValue ()
   }

   private def getDoubleValue () {
     2 * value
   }

   static getStaticValue () {
     0
   }
}

means

interface MyTrait {
   def getValue ()

  public static class Trait {
   public static def getValue (MyTrait self) {
      self.getDoubleValue ()
   }

   private static def getDoubleValue (MyTrait self) {
     2 * self.value
   }

   static getStaticValue () {
     0
   }
  }
}

(Q2) how to call the original method?

Do you mean how you call  trait method from Object implementing trait?
Because in my concept own methods of class has priority under methods
of trait. BTW, it is a big difference with runtime mixins because in
case of mixin you want to replace method of original class.

My idea is to use TraitClass.this.method notation to call Trait
method. But I am open to other good suggestions

class X extends Y implements Z with MyTrait {
   int myValue

   def getValue () {
      MyTrait.this.getValue ()
   }
}

(Q3) can I maintain a static state in the toolbox?

Yes you can

static non-final fields of trait becomes static fields of inner class
and involved in to creation of property index

(Q4) can I maintain a non static state in the toolbox?

Short answer is no.

The long answer is yes, we can try. If non-abstract class doesn't
implement some getters/setters required by parent trait we can
automatically create necessary properties.

I am also pretty much like a idea of transforming uninitialized
properties in to getter/setter definition.

trait MyTrait {
   def value
}

class X with MyTrait {
}

means

interface MyTrait {
   def getValue ()
   void setValue (newValue)
}

class X implements MyTrait {
  def value
}

(Q5) How will a closure resolve its methods/properties when in the toolbox?

I think it should do it exactly on natural way - 'self' becomes owner
and delegate when closure created as 'this' does in normal code.

(Q6) is the toolbox getProperty/setProperty/invokeMethod/missingMethod
method overwriting the one in the class th toolbox is applied to?

I think yes in case if class or super classes doesn't provide their
own (non-syntetic) implementation

(Q7) can a toolbox provide a constructor?

Yes.
But you should call it manually from 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?

see above

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

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

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

    http://xircles.codehaus.org/manage_email