« Return to Thread: mixins etc.
Re: mixins etc.
by Graeme Rocher-2
::
Rate this Message:
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
<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
« Return to Thread: mixins etc.
| Free Forum Powered by Nabble | Forum Help |