« Return to Thread: mixins etc.

Re: mixins etc.

by Graeme Rocher-2 :: Rate this Message:

Reply to Author | View in Thread

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


 « Return to Thread: mixins etc.