mixins etc.

[Alex Tkachman]

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

[Andres Almiray]

Great! though I would like to see what Luke and Alexandru bring to the table,
as they were also looking into mixins for Groovy (Luke made Injecto after all)

-- Andres

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

[Dierk König]

cool ;-)

Thanks a lot for the implementation and the comprehensive
description!

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

... except that categories can be used to define
methods on a combination of classes that work together
to fulfill a common purpose. E.g.
defining something like

class IntCodec {
    static String encode (Integer self) { ... }
    static Integer decode (String self) { ... }
}

is not possible with mixins, since they only affect
one class at a time.

Right?

Also, categories have a scope of use. Mixins don't,
right?

Is there also any difference in the affected threads?
(I vaguely remember this has been discussed on the
list before... sorry)

| simple use of it
|
| ArrayList.mixin ArrayListExt

how about setting the scope like

ArrayList.mixin (ArrayListExt) {
    // new methods available here
}
// but not here anymore

?

| @Mixin(MyClassExt)
| class MyClass {
|      def result () {
|          longRunningJavaMethod ()
|      }
| }
|
| and write for example in Java
|
| public MyClassExt {
|          public static Set<Collection> longRunningJavaMethod (MyClass
| self) { /// }
| }

so cool and very powerful ;-)

reminds me on my old Ruby days...


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

dito

| 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

well explained!

Now how about this:

class A { def foo() {'A'} }
class B extends A { def foo() {'B'} }      // subclass overrides method

class M { static void foo(A self) {'M'} }  // mixin redefines method

A.mixin M

println( new B().foo() )

???? %-)

cheers
Dierk

[Alex Tkachman]

See comments below

On Wed, Apr 9, 2008 at 11:36 AM, Dierk König <dierk.koenig@...> wrote:

>
>
>
> cool ;-)
>
>  Thanks a lot for the implementation and the comprehensive
>  description!
>
>
>  | 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 "
>  |    }
>  | }
>
>  ... except that categories can be used to define
>  methods on a combination of classes that work together
>  to fulfill a common purpose. E.g.
>  defining something like
>
>  class IntCodec {
>      static String encode (Integer self) { ... }
>      static Integer decode (String self) { ... }
>  }
>
>  is not possible with mixins, since they only affect
>  one class at a time.
>
>  Right?
>

In this case you will need to apply mixin separately to String and Integer.

Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
Jochen noticed in thread on global categories it brings a bit too much
danger, so right now this functionality is banned. But it is very easy
to return it back :)

>  Also, categories have a scope of use. Mixins don't,
>  right?
>

Right, mixins has no scope.

>  Is there also any difference in the affected threads?
>  (I vaguely remember this has been discussed on the
>  list before... sorry)
>
>

No threading involved. Another difference from categories.

>  | simple use of it
>  |
>  | ArrayList.mixin ArrayListExt
>
>  how about setting the scope like
>
>  ArrayList.mixin (ArrayListExt) {
>      // new methods available here
>  }
>  // but not here anymore
>
>

Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
is equivalent to using category.

>  ?
>
>  | @Mixin(MyClassExt)
>  | class MyClass {
>  |      def result () {
>  |          longRunningJavaMethod ()
>  |      }
>  | }
>  |
>  | and write for example in Java
>  |
>  | public MyClassExt {
>  |          public static Set<Collection> longRunningJavaMethod (MyClass
>  | self) { /// }
>  | }
>
>  so cool and very powerful ;-)
>
>  reminds me on my old Ruby days...
>
>
>
>  | Another nice feature for groovy objects is ability to do per
>  | instance mixins
>
>  dito
>
>
>  | 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
>
>  well explained!
>
>  Now how about this:
>
>  class A { def foo() {'A'} }
>  class B extends A { def foo() {'B'} }      // subclass overrides method
>
>  class M { static void foo(A self) {'M'} }  // mixin redefines method
>
>  A.mixin M
>
>  println( new B().foo() )
>
>  ???? %-)
>

In theory expected behaviour is to print 'B' because B defines more
specific method. But new B().super.foo () (not legal syntax of course)
should print 'M' In practice, test case needed :)

>  cheers
>  Dierk

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

    http://xircles.codehaus.org/manage_email

[Robert O'Connor]

Alex, good job! I played with your mixin syntax in an unsavory way, overloaded the subtraction operator to add the two integers: http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html

Again, good job!
-rob
Alex Tkachman wrote:

See comments below

On Wed, Apr 9, 2008 at 11:36 AM, Dierk König dierk.koenig@... wrote:
  

cool ;-)

 Thanks a lot for the implementation and the comprehensive
 description!


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

 ... except that categories can be used to define
 methods on a combination of classes that work together
 to fulfill a common purpose. E.g.
 defining something like

 class IntCodec {
     static String encode (Integer self) { ... }
     static Integer decode (String self) { ... }
 }

 is not possible with mixins, since they only affect
 one class at a time.

 Right?

    

In this case you will need to apply mixin separately to String and Integer.

Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
Jochen noticed in thread on global categories it brings a bit too much
danger, so right now this functionality is banned. But it is very easy
to return it back :)

  

 Also, categories have a scope of use. Mixins don't,
 right?

    

Right, mixins has no scope.

  

 Is there also any difference in the affected threads?
 (I vaguely remember this has been discussed on the
 list before... sorry)


    

No threading involved. Another difference from categories.

  

 | simple use of it
 |
 | ArrayList.mixin ArrayListExt

 how about setting the scope like

 ArrayList.mixin (ArrayListExt) {
     // new methods available here
 }
 // but not here anymore


    

Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
is equivalent to using category.

  

 ?

 | @Mixin(MyClassExt)
 | class MyClass {
 |      def result () {
 |          longRunningJavaMethod ()
 |      }
 | }
 |
 | and write for example in Java
 |
 | public MyClassExt {
 |          public static Set<Collection> longRunningJavaMethod (MyClass
 | self) { /// }
 | }

 so cool and very powerful ;-)

 reminds me on my old Ruby days...



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

 dito


 | 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

 well explained!

 Now how about this:

 class A { def foo() {'A'} }
 class B extends A { def foo() {'B'} }      // subclass overrides method

 class M { static void foo(A self) {'M'} }  // mixin redefines method

 A.mixin M

 println( new B().foo() )

 ???? %-)

    

In theory expected behaviour is to print 'B' because B defines more
specific method. But new B().super.foo () (not legal syntax of course)
should print 'M' In practice, test case needed :)

  

 cheers
 Dierk
    

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

    http://xircles.codehaus.org/manage_email



  

[Alex Tkachman]

Thank you, Rob. But please be aware that it is experimental feature
and can be reverted from trunk in any moment or seriously modifed.
I mean it is a bit too early to popularize it :)

On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor <rob@...> wrote:

>
>  Alex, good job! I played with your mixin syntax in an unsavory way,
> overloaded the subtraction operator to add the two integers:
> http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html
>
>  Again, good job!
>  -rob
>  Alex Tkachman wrote:
>
>  See comments below
>
> On Wed, Apr 9, 2008 at 11:36 AM, Dierk König <dierk.koenig@...> wrote:
>
>
>
> cool ;-)
>
>  Thanks a lot for the implementation and the comprehensive
>  description!
>
>
>  | 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 "
>  | }
>  | }
>
>  ... except that categories can be used to define
>  methods on a combination of classes that work together
>  to fulfill a common purpose. E.g.
>  defining something like
>
>  class IntCodec {
>  static String encode (Integer self) { ... }
>  static Integer decode (String self) { ... }
>  }
>
>  is not possible with mixins, since they only affect
>  one class at a time.
>
>  Right?
>
>
>  In this case you will need to apply mixin separately to String and Integer.
>
> Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
> Jochen noticed in thread on global categories it brings a bit too much
> danger, so right now this functionality is banned. But it is very easy
> to return it back :)
>
>
>
>  Also, categories have a scope of use. Mixins don't,
>  right?
>
>
>  Right, mixins has no scope.
>
>
>
>  Is there also any difference in the affected threads?
>  (I vaguely remember this has been discussed on the
>  list before... sorry)
>
>
>
>  No threading involved. Another difference from categories.
>
>
>
>  | simple use of it
>  |
>  | ArrayList.mixin ArrayListExt
>
>  how about setting the scope like
>
>  ArrayList.mixin (ArrayListExt) {
>  // new methods available here
>  }
>  // but not here anymore
>
>
>
>  Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
> is equivalent to using category.
>
>
>
>  ?
>
>  | @Mixin(MyClassExt)
>  | class MyClass {
>  | def result () {
>  | longRunningJavaMethod ()
>  | }
>  | }
>  |
>  | and write for example in Java
>  |
>  | public MyClassExt {
>  | public static Set<Collection> longRunningJavaMethod (MyClass
>  | self) { /// }
>  | }
>
>  so cool and very powerful ;-)
>
>  reminds me on my old Ruby days...
>
>
>
>  | Another nice feature for groovy objects is ability to do per
>  | instance mixins
>
>  dito
>
>
>  | 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
>
>  well explained!
>
>  Now how about this:
>
>  class A { def foo() {'A'} }
>  class B extends A { def foo() {'B'} } // subclass overrides method
>
>  class M { static void foo(A self) {'M'} } // mixin redefines method
>
>  A.mixin M
>
>  println( new B().foo() )
>
>  ???? %-)
>
>
>  In theory expected behaviour is to print 'B' because B defines more
> specific method. But new B().super.foo () (not legal syntax of course)
> should print 'M' In practice, test case needed :)
>
>
>
>  cheers
>  Dierk
>
>
> ---------------------------------------------------------------------
> 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

[Robert O'Connor]

Shrug, it comes with the territory of using unreleased code :) I linked the mailing list post, so if people read it, they'll know this... but regardless, i like it. Also, mixins classes can only contain one method right? I ran into a lovely erm, StackOverFlow when i added more than one method to my mixin class..
Alex Tkachman wrote:

Thank you, Rob. But please be aware that it is experimental feature
and can be reverted from trunk in any moment or seriously modifed.
I mean it is a bit too early to popularize it :)

On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor rob@... wrote:
  

 Alex, good job! I played with your mixin syntax in an unsavory way,
overloaded the subtraction operator to add the two integers:
http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html

 Again, good job!
 -rob
 Alex Tkachman wrote:

 See comments below

On Wed, Apr 9, 2008 at 11:36 AM, Dierk König dierk.koenig@... wrote:



cool ;-)

 Thanks a lot for the implementation and the comprehensive
 description!


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

 ... except that categories can be used to define
 methods on a combination of classes that work together
 to fulfill a common purpose. E.g.
 defining something like

 class IntCodec {
 static String encode (Integer self) { ... }
 static Integer decode (String self) { ... }
 }

 is not possible with mixins, since they only affect
 one class at a time.

 Right?


 In this case you will need to apply mixin separately to String and Integer.

Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
Jochen noticed in thread on global categories it brings a bit too much
danger, so right now this functionality is banned. But it is very easy
to return it back :)



 Also, categories have a scope of use. Mixins don't,
 right?


 Right, mixins has no scope.



 Is there also any difference in the affected threads?
 (I vaguely remember this has been discussed on the
 list before... sorry)



 No threading involved. Another difference from categories.



 | simple use of it
 |
 | ArrayList.mixin ArrayListExt

 how about setting the scope like

 ArrayList.mixin (ArrayListExt) {
 // new methods available here
 }
 // but not here anymore



 Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
is equivalent to using category.



 ?

 | @Mixin(MyClassExt)
 | class MyClass {
 | def result () {
 | longRunningJavaMethod ()
 | }
 | }
 |
 | and write for example in Java
 |
 | public MyClassExt {
 | public static Set<Collection> longRunningJavaMethod (MyClass
 | self) { /// }
 | }

 so cool and very powerful ;-)

 reminds me on my old Ruby days...



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

 dito


 | 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

 well explained!

 Now how about this:

 class A { def foo() {'A'} }
 class B extends A { def foo() {'B'} } // subclass overrides method

 class M { static void foo(A self) {'M'} } // mixin redefines method

 A.mixin M

 println( new B().foo() )

 ???? %-)


 In theory expected behaviour is to print 'B' because B defines more
specific method. But new B().super.foo () (not legal syntax of course)
should print 'M' In practice, test case needed :)



 cheers
 Dierk


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



  

[Alex Tkachman]

Could you provide test case please. It will help to fix :)

On Wed, Apr 9, 2008 at 12:20 PM, Robert O'Connor <rob@...> wrote:

>
>  Shrug, it comes with the territory of using unreleased code :) I linked the
> mailing list post, so if people read it, they'll know this... but
> regardless, i like it. Also, mixins classes can only contain one method
> right? I ran into a lovely erm, StackOverFlow when i added more than one
> method to my mixin class..
>
>
>  Alex Tkachman wrote:
>  Thank you, Rob. But please be aware that it is experimental feature
> and can be reverted from trunk in any moment or seriously modifed.
> I mean it is a bit too early to popularize it :)
>
> On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor <rob@...> wrote:
>
>
>  Alex, good job! I played with your mixin syntax in an unsavory way,
> overloaded the subtraction operator to add the two integers:
> http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html
>
>  Again, good job!
>  -rob
>  Alex Tkachman wrote:
>
>  See comments below
>
> On Wed, Apr 9, 2008 at 11:36 AM, Dierk König <dierk.koenig@...> wrote:
>
>
>
> cool ;-)
>
>  Thanks a lot for the implementation and the comprehensive
>  description!
>
>
>  | 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 "
>  | }
>  | }
>
>  ... except that categories can be used to define
>  methods on a combination of classes that work together
>  to fulfill a common purpose. E.g.
>  defining something like
>
>  class IntCodec {
>  static String encode (Integer self) { ... }
>  static Integer decode (String self) { ... }
>  }
>
>  is not possible with mixins, since they only affect
>  one class at a time.
>
>  Right?
>
>
>  In this case you will need to apply mixin separately to String and Integer.
>
> Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
> Jochen noticed in thread on global categories it brings a bit too much
> danger, so right now this functionality is banned. But it is very easy
> to return it back :)
>
>
>
>  Also, categories have a scope of use. Mixins don't,
>  right?
>
>
>  Right, mixins has no scope.
>
>
>
>  Is there also any difference in the affected threads?
>  (I vaguely remember this has been discussed on the
>  list before... sorry)
>
>
>
>  No threading involved. Another difference from categories.
>
>
>
>  | simple use of it
>  |
>  | ArrayList.mixin ArrayListExt
>
>  how about setting the scope like
>
>  ArrayList.mixin (ArrayListExt) {
>  // new methods available here
>  }
>  // but not here anymore
>
>
>
>  Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
> is equivalent to using category.
>
>
>
>  ?
>
>  | @Mixin(MyClassExt)
>  | class MyClass {
>  | def result () {
>  | longRunningJavaMethod ()
>  | }
>  | }
>  |
>  | and write for example in Java
>  |
>  | public MyClassExt {
>  | public static Set<Collection> longRunningJavaMethod (MyClass
>  | self) { /// }
>  | }
>
>  so cool and very powerful ;-)
>
>  reminds me on my old Ruby days...
>
>
>
>  | Another nice feature for groovy objects is ability to do per
>  | instance mixins
>
>  dito
>
>
>  | 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
>
>  well explained!
>
>  Now how about this:
>
>  class A { def foo() {'A'} }
>  class B extends A { def foo() {'B'} } // subclass overrides method
>
>  class M { static void foo(A self) {'M'} } // mixin redefines method
>
>  A.mixin M
>
>  println( new B().foo() )
>
>  ???? %-)
>
>
>  In theory expected behaviour is to print 'B' because B defines more
> specific method. But new B().super.foo () (not legal syntax of course)
> should print 'M' In practice, test case needed :)
>
>
>
>  cheers
>  Dierk
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Robert O'Connor]

class FooExt {
       static def minus(int self, int other) {
             self + other
      }
     static def plus(int self, int other) {
             self - other
      }
}
Integer.mixin FooExt

assert  5 + 5 == 0

assert 5 - 5 == 10

The above script pretty much.

Alex Tkachman wrote:

Could you provide test case please. It will help to fix :)

On Wed, Apr 9, 2008 at 12:20 PM, Robert O'Connor rob@... wrote:
  

 Shrug, it comes with the territory of using unreleased code :) I linked the
mailing list post, so if people read it, they'll know this... but
regardless, i like it. Also, mixins classes can only contain one method
right? I ran into a lovely erm, StackOverFlow when i added more than one
method to my mixin class..


 Alex Tkachman wrote:
 Thank you, Rob. But please be aware that it is experimental feature
and can be reverted from trunk in any moment or seriously modifed.
I mean it is a bit too early to popularize it :)

On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor rob@... wrote:


 Alex, good job! I played with your mixin syntax in an unsavory way,
overloaded the subtraction operator to add the two integers:
http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html

 Again, good job!
 -rob
 Alex Tkachman wrote:

 See comments below

On Wed, Apr 9, 2008 at 11:36 AM, Dierk König dierk.koenig@... wrote:



cool ;-)

 Thanks a lot for the implementation and the comprehensive
 description!


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

 ... except that categories can be used to define
 methods on a combination of classes that work together
 to fulfill a common purpose. E.g.
 defining something like

 class IntCodec {
 static String encode (Integer self) { ... }
 static Integer decode (String self) { ... }
 }

 is not possible with mixins, since they only affect
 one class at a time.

 Right?


 In this case you will need to apply mixin separately to String and Integer.

Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
Jochen noticed in thread on global categories it brings a bit too much
danger, so right now this functionality is banned. But it is very easy
to return it back :)



 Also, categories have a scope of use. Mixins don't,
 right?


 Right, mixins has no scope.



 Is there also any difference in the affected threads?
 (I vaguely remember this has been discussed on the
 list before... sorry)



 No threading involved. Another difference from categories.



 | simple use of it
 |
 | ArrayList.mixin ArrayListExt

 how about setting the scope like

 ArrayList.mixin (ArrayListExt) {
 // new methods available here
 }
 // but not here anymore



 Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
is equivalent to using category.



 ?

 | @Mixin(MyClassExt)
 | class MyClass {
 | def result () {
 | longRunningJavaMethod ()
 | }
 | }
 |
 | and write for example in Java
 |
 | public MyClassExt {
 | public static Set<Collection> longRunningJavaMethod (MyClass
 | self) { /// }
 | }

 so cool and very powerful ;-)

 reminds me on my old Ruby days...



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

 dito


 | 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

 well explained!

 Now how about this:

 class A { def foo() {'A'} }
 class B extends A { def foo() {'B'} } // subclass overrides method

 class M { static void foo(A self) {'M'} } // mixin redefines method

 A.mixin M

 println( new B().foo() )

 ???? %-)


 In theory expected behaviour is to print 'B' because B defines more
specific method. But new B().super.foo () (not legal syntax of course)
should print 'M' In practice, test case needed :)



 cheers
 Dierk


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






    

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

    http://xircles.codehaus.org/manage_email



  

[Robert O'Connor]

Let me make sure i understand the Mixin annotation: it's for if the Mixin extension is written in a java class?
Alex Tkachman wrote:

Could you provide test case please. It will help to fix :)

On Wed, Apr 9, 2008 at 12:20 PM, Robert O'Connor rob@... wrote:
  

 Shrug, it comes with the territory of using unreleased code :) I linked the
mailing list post, so if people read it, they'll know this... but
regardless, i like it. Also, mixins classes can only contain one method
right? I ran into a lovely erm, StackOverFlow when i added more than one
method to my mixin class..


 Alex Tkachman wrote:
 Thank you, Rob. But please be aware that it is experimental feature
and can be reverted from trunk in any moment or seriously modifed.
I mean it is a bit too early to popularize it :)

On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor rob@... wrote:


 Alex, good job! I played with your mixin syntax in an unsavory way,
overloaded the subtraction operator to add the two integers:
http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html

 Again, good job!
 -rob
 Alex Tkachman wrote:

 See comments below

On Wed, Apr 9, 2008 at 11:36 AM, Dierk König dierk.koenig@... wrote:



cool ;-)

 Thanks a lot for the implementation and the comprehensive
 description!


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

 ... except that categories can be used to define
 methods on a combination of classes that work together
 to fulfill a common purpose. E.g.
 defining something like

 class IntCodec {
 static String encode (Integer self) { ... }
 static Integer decode (String self) { ... }
 }

 is not possible with mixins, since they only affect
 one class at a time.

 Right?


 In this case you will need to apply mixin separately to String and Integer.

Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
Jochen noticed in thread on global categories it brings a bit too much
danger, so right now this functionality is banned. But it is very easy
to return it back :)



 Also, categories have a scope of use. Mixins don't,
 right?


 Right, mixins has no scope.



 Is there also any difference in the affected threads?
 (I vaguely remember this has been discussed on the
 list before... sorry)



 No threading involved. Another difference from categories.



 | simple use of it
 |
 | ArrayList.mixin ArrayListExt

 how about setting the scope like

 ArrayList.mixin (ArrayListExt) {
 // new methods available here
 }
 // but not here anymore



 Assuming that ArrayListExt effects ArrayList (and hierarchy) only it
is equivalent to using category.



 ?

 | @Mixin(MyClassExt)
 | class MyClass {
 | def result () {
 | longRunningJavaMethod ()
 | }
 | }
 |
 | and write for example in Java
 |
 | public MyClassExt {
 | public static Set<Collection> longRunningJavaMethod (MyClass
 | self) { /// }
 | }

 so cool and very powerful ;-)

 reminds me on my old Ruby days...



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

 dito


 | 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

 well explained!

 Now how about this:

 class A { def foo() {'A'} }
 class B extends A { def foo() {'B'} } // subclass overrides method

 class M { static void foo(A self) {'M'} } // mixin redefines method

 A.mixin M

 println( new B().foo() )

 ???? %-)


 In theory expected behaviour is to print 'B' because B defines more
specific method. But new B().super.foo () (not legal syntax of course)
should print 'M' In practice, test case needed :)



 cheers
 Dierk


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






    

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

    http://xircles.codehaus.org/manage_email



  

[Graeme Rocher-2]

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

So this should be possible where a reference to "this" refers to the
mixed in class:

class IntCodec {
    Integer decode () {
          decodeInteger(this)
     }
}

Integer.mixin IntCodec

I won't be happy with the implementation until this is implemented as
the first argument thing reminds me of Perl and brings back horrible
memories :-)

Also the static keyword should be used to differentiate between static
and instance methods on a mixin. So for example:

class IntCodec {
    static Integer decodeInt(int n) {
          decodeInteger(n)
     }

    Integer decode () {
          decodeInteger(this)
     }
}

The above should act like:

Integer.mixin IntCode

assert "stuff" == Integer.decodeInt(1)
assert "stuff" == 1.decode()

Otherwise you have the same limitations as categories

Cheers

On Wed, Apr 9, 2008 at 8:36 AM, Dierk König <dierk.koenig@...> wrote:

>
>
>
> cool ;-)
>
>  Thanks a lot for the implementation and the comprehensive
>  description!
>
>
>  | 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 "
>  |    }
>  | }
>
>  ... except that categories can be used to define
>  methods on a combination of classes that work together
>  to fulfill a common purpose. E.g.
>  defining something like
>
>  class IntCodec {
>      static String encode (Integer self) { ... }
>      static Integer decode (String self) { ... }
>  }
>
>  is not possible with mixins, since they only affect
>  one class at a time.
>
>  Right?
>
>  Also, categories have a scope of use. Mixins don't,
>  right?
>
>  Is there also any difference in the affected threads?
>  (I vaguely remember this has been discussed on the
>  list before... sorry)
>
>
>  | simple use of it
>  |
>  | ArrayList.mixin ArrayListExt
>
>  how about setting the scope like
>
>  ArrayList.mixin (ArrayListExt) {
>      // new methods available here
>  }
>  // but not here anymore
>
>
>  ?
>
>  | @Mixin(MyClassExt)
>  | class MyClass {
>  |      def result () {
>  |          longRunningJavaMethod ()
>  |      }
>  | }
>  |
>  | and write for example in Java
>  |
>  | public MyClassExt {
>  |          public static Set<Collection> longRunningJavaMethod (MyClass
>  | self) { /// }
>  | }
>
>  so cool and very powerful ;-)
>
>  reminds me on my old Ruby days...
>
>
>
>  | Another nice feature for groovy objects is ability to do per
>  | instance mixins
>
>  dito
>
>
>  | 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
>
>  well explained!
>
>  Now how about this:
>
>  class A { def foo() {'A'} }
>  class B extends A { def foo() {'B'} }      // subclass overrides method
>
>  class M { static void foo(A self) {'M'} }  // mixin redefines method
>
>  A.mixin M
>
>  println( new B().foo() )
>
>  ???? %-)
>
>  cheers
>  Dierk

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

If you have alook on mixin you will understand what's going on.

Overidden plus calls minus, which overidden as well and calls plus
again, which calls minus etc. Trap.

And unfortunately there is no way to call original 'plus'

On Wed, Apr 9, 2008 at 12:25 PM, Robert O'Connor <rob@...> wrote:

>
>  class FooExt {
>         static def minus(int self, int other) {
>               self + other
>        }
>       static def plus(int self, int other) {
>               self - other
>        }
>  }
>  Integer.mixin FooExt
>
>  assert  5 + 5 == 0
>
>  assert 5 - 5 == 10
>
>  The above script pretty much.
>
>
>  Alex Tkachman wrote:
>  Could you provide test case please. It will help to fix :)
>
> On Wed, Apr 9, 2008 at 12:20 PM, Robert O'Connor <rob@...> wrote:
>
>
>  Shrug, it comes with the territory of using unreleased code :) I linked the
> mailing list post, so if people read it, they'll know this... but
> regardless, i like it. Also, mixins classes can only contain one method
> right? I ran into a lovely erm, StackOverFlow when i added more than one
> method to my mixin class..
>
>
>  Alex Tkachman wrote:
>  Thank you, Rob. But please be aware that it is experimental feature
> and can be reverted from trunk in any moment or seriously modifed.
> I mean it is a bit too early to popularize it :)
>
> On Wed, Apr 9, 2008 at 12:01 PM, Robert O'Connor <rob@...> wrote:
>
>
>  Alex, good job! I played with your mixin syntax in an unsavory way,
> overloaded the subtraction operator to add the two integers:
> http://robbyoconnor.blogspot.com/2008/04/new-groovy-mixins-syntax.html
>
>  Again, good job!
>  -rob
>  Alex Tkachman wrote:
>
>  See comments below
>
> On Wed, Apr 9, 2008 at 11:36 AM, Dierk König <dierk.koenig@...> wrote:
>
>
>
> cool ;-)
>
>  Thanks a lot for the implementation and the comprehensive
>  description!
>
>
>  | 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 "
>  | }
>  | }
>
>  ... except that categories can be used to define
>  methods on a combination of classes that work together
>  to fulfill a common purpose. E.g.
>  defining something like
>
>  class IntCodec {
>  static String encode (Integer self) { ... }
>  static Integer decode (String self) { ... }
>  }
>
>  is not possible with mixins, since they only affect
>  one class at a time.
>
>  Right?
>
>
>  In this case you will need to apply mixin separately to String and Integer.
>
> Initially I had syntax DefaultGroovyMethods.mixin IntCodec but as
> Jochen noticed in thread on global categories it brings a bit too much
> danger, so right now this functionality is banned. But it is very easy
> to return it back :)
>
>
>
>  Also, categories have a scope of use. Mixins don't,
>  right?
>
>
>  Right, mixins has no scope.
>
>
>
>  Is there also any difference in the affected threads?
>  (I vaguely remember this has been discussed on the
>  list before... sorry)
>
>
>
>  No threading involved. Another difference from categories.
>
>
>
>  | simple use of it
>  |
>  | ArrayList.mixin ArrayListExt
>
>  how about setting the scope like
>
>  ArrayList.mixin (ArrayListExt) {
>  // new methods available here
>  }
>  // but not here anymore
>
>
>
>  Assuming that ArrayListExt effects ArrayList (and hie