Mixins

[Marek Kozieł]

2012/1/24 Behrang Saeedzadeh <behrangsa at gmail.com>:
> Hi all,
>
> What's the general consensus regarding supporting mixins in Java 8 (or 9,
> etc.)? The more I use them, the more I like them. I especially like them
> for organizing code -- different categories of responsibility for a class
> are encapsulated in different mixins, for example:
>
> public class AccountManagement {
>   mixin Authentication;
>   mixin Authorization;
>   mixin Administration;
> }
>
> Cheers,
> Behrang Saeedzadeh
> http://www.behrang.org

At first I was thinking for same solution but there are nasty problems
that comes with it:
 - First of all such solution breaks logic spaces.
   The final solution that you aiming for look like:
       AccountManagement am = ...;
       am.{Authentication space}methodName();
       am.{Authorization space}methodName();
       am.{Administration space}methodName();
but by removing/not including space phrase you loose your hard work.
What more there no easy way for controlling logic flow(like logic
intersection) in current Java.

 - it will increase method names & javadoc collisions

 - it will be harder to imagine object tree

 - people will have more occasions to damage existing/working code
without noticing.
  Such 'future' would bring programing closer to continuous
projecting, which is good only in small projects where all inherited
classes can be checked. Because in large scale projects adding one
small method can bring a disaster.

class SomeDate {...}
class ImmutableDate extend SomeDate{...}
who could predict all possible problems after adding some ''nice''
method that allows to modify SomeDate fields?


Try reading about glue classes(there are still few thing that would
have to be analyzed for this solution):

For those and others reasons i thought about solution that:
 - Support splitting key functionality from additional functionality -
which is important for projecting time and amount of bugs. I often get
myself preoccupied with determining all methods that will be required
& interactions between them & possible interacting with inheritance.
So I thought that solution that will split(or just allow for it) key
functionality apart from other methods would be great.

- Will not allow for mixing logic spaces without warning.

- Will not allow additional functionality to become important one.

- Will support generics & arrays

- IDE will be able to present it in simple matter.

All above reasons suggested solution that will allow programmer to use
static methods and call them right 'from' proper object
object..glueMethod(...);
would be resolved to ...glueClass.glueMethod(object,...)
// as you can see NPE behavior could be controlled by such solution as
well if there is need for it.

W dniu 23 marca 2009 06:10 użytkownik Jeremy Manson
<jeremy.manson at gmail.com> napisał:
> I believe that what Marek is trying to do is to introduce a feature
> that allows you to add (or glue) methods to existing classes.  You
> could have, for example:
>
> // Glue class to add sorting to Lists
> class Sort<T> glue(List<T>) {
>  void sort(List<T> l) {
>    // sorts the argument
>  }
> }
>
> And then later say:
>
> List<Integer> list = new ArrayList<Integer>();
> // adds elements to list
> list..sort();  // The ".." notation invokes Sort.sort() on list.
>

I failed to describe it in easy way / but maybe you will find it interesting:

http://lasu2string.blogspot.com/2009/03/glue-classes-proposal.html
http://lasu2string.blogspot.com/2009/03/glue-classes-proposal-09.html
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/subject.html#769

-- 
Regards.
Lasu aka Marek Kozieł

http://na-chlodno.blogspot.com/
http://lasu2string.blogspot.com/