The Artima Developer Community
Sponsored Link

Weblogs Forum
Mixins: Something Else You Can't Do With Java Generics?

27 replies on 2 pages. Most recent reply: Jan 2, 2006 9:30 PM by Matt O'Connor

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 27 replies on 2 pages [ « | 1 2 ]
Scott Carlson

Posts: 1
Nickname: scarlson
Registered: Oct, 2005

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 22, 2005 7:21 PM
Reply to this message Reply
Advertisement
I believe I've done this with Dynamic Proxies in Java. Basically, as long as the Mixin is an interface. Proxy can create a class that implements all of the interfaces you specify, your InvocationHandler just needs to take your Mixin and the object that is mixing with, and dispatch to the correct object based on the method being executed.

Let me know if you need some example code...

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 23, 2005 7:55 AM
Reply to this message Reply
> I believe I've done this with Dynamic Proxies in Java.
> Basically, as long as the Mixin is an interface. Proxy
> y can create a class that implements all of the interfaces
> you specify, your InvocationHandler just needs to take
> your Mixin and the object that is mixing with, and
> dispatch to the correct object based on the method being
> executed.
>
> Let me know if you need some example code...

It would be intesting to see my Mixins.java example expressed this way, since I've also done it using the Decorator. That way it could be compared.

unmesh

Posts: 15
Nickname: unmesh
Registered: May, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 23, 2005 10:57 PM
Reply to this message Reply
Hi,

I have used and found following pattern useful
http://www.cs.luc.edu/users/laufer/teaching/473/handouts/AbstractSubclasses.html
It describes how you can simulate mixins in java. I have used this technique in one of my projects. Major advantange I think mixins provide is module reusability. If you want to reuse just using inheritance, you have to duplicate either base or derived class definitions.

There is very good discussion on Mixins in following papers
by Gilad Bracha (Who also implemented Java Generics)
http://bracha.org/modularity-meets-inheritance.ps
http://bracha.org/jigsaw.ps (Phd thesis)

Thanks,
Unmesh

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 24, 2005 5:38 AM
Reply to this message Reply
> Hi,
>
> I have used and found following pattern useful
> http://www.cs.luc.edu/users/laufer/teaching/473/handouts/Ab
> stractSubclasses.html
> It describes how you can simulate mixins in java. I have
> used this technique in one of my projects. Major
> advantange I think mixins provide is module reusability.
> If you want to reuse just using inheritance, you have to
> duplicate either base or derived class definitions.

I'm not sure how you could have used this technique. His final section "Implementation in Java?" says that this approach does not work. The code he shows will not compile, and he explains why. That article is an exploration and description of the problems, but not a solution.

Perhaps you have an example that shows how you have applied this technique?

unmesh

Posts: 15
Nickname: unmesh
Registered: May, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 24, 2005 5:34 PM
Reply to this message Reply
Its not possible to extend existing class as template parameter. But you can simulate inheritance explicitly. Here is the example from the same site.

/**
* Application-independent support for base classes and mixin classes.
* Conceptually, an instance of this class has a superclass instance
* (whose methods are statically bound) and a current receiver
* (whose methods are dynamically bound).
*/

class Composable {

/**
* The static superclass instance for this object, that is, the next
* object up the conceptual inheritance hierarchy.
*/

protected Composable zuper;

/**
* The dynamic receiver instance for this object, that is, the object
* at the bottom of the conceptual inheritance hierarchy (beginning
* of the chain of responsibility).
*/

protected Composable thiz;

/**
* This methods sets the superclass instance for this object.
*/

private void setSuper(Composable zuper) {
this.zuper = zuper;
System.out.println(this + ".zuper = " + zuper);
}

/**
* This method recursively sets the current receiver for this object
* and its conceptual superclass instances.
*/

private void setThis(Composable thiz) {
this.thiz = thiz;
System.out.println(this + ".thiz = " + thiz);
if (zuper != null) {
zuper.setThis(thiz);
}
}

protected Composable(Composable zuper) {
setSuper(zuper);
setThis(this);
}

protected Composable() { this(null); }
}

/**
* A basic collection.
*/

interface Collection {
void insert(Object item);
Object remove();
void clear();
boolean isEmpty();
}

/**
* Application-specific support for base classes. Subclasses should
* implement all methods in the application-specific interface, that is,
* Collection. For convenience, it provides application-specific
* accessor methods for thiz and zuper.
*/

abstract class CollectionBase extends Composable implements Collection {
protected CollectionBase() { }
protected CollectionBase(Composable zuper) { super(zuper); }
protected Collection getThis() { return (Collection) thiz; }
protected Collection getSuper() { return (Collection) zuper; }
}

/**
* Application-specific support for mixin classes. Subclasses should only
* implement those methods in the application-specific interface that they
* want to refine. For convenience, it provides default implementations
* of all methods in the application-specific interface; this simulates
* method inheritance.
*/

abstract class CollectionMixin extends CollectionBase {
protected CollectionMixin(Composable zuper) { super(zuper); }
public void insert(Object item) { getSuper().insert(item); }
public Object remove() { return getSuper().remove(); }
public void clear() { getSuper().clear(); }
public boolean isEmpty() { return getSuper().isEmpty(); }
}

/**
* An example implementation of Collection to be used as a base class.
* Note that methods that the subclass possibly refines must be invoked
* via getThis.
*/

class Queue extends CollectionBase {
private LinkedList items = new LinkedList();
public void insert(Object item) { items.addLast(item); }
public Object remove() { return items.removeFirst(); }
public void clear() {
while (! getThis().isEmpty()) {
getThis().remove();
}
}
public boolean isEmpty() { return items.isEmpty(); }
}

/**
* An example implementation of Collection to be used as an
* abstract subclass (mixin) for adding the SizeOf capability
* to an arbitrary Collection implementation. Note that methods
* from the superclass in the conceptual sense must be invoked
* via getSuper.
*/

class SizeOf extends CollectionMixin {
private int count;
public SizeOf(CollectionBase zuper) { super(zuper); }
public void insert(Object item) {
getSuper().insert(item);
count ++;
}
public Object remove() {
Object result = getSuper().remove();
if (result != null) {
count --;
}
return result;
}
public int size() { return count; }
}

/**
* An example implementation of Collection to be used as an
* abstract subclass (mixin) for adding the Verbose capability
* (reporting on every operation) to an arbitrary Collection
* implementation.
*/

class Verbose extends CollectionMixin {
public Verbose(CollectionBase zuper) { super(zuper); }
public void insert(Object item) {
getSuper().insert(item);
System.out.println(this + ".insert(" + item + ")");
}
public Object remove() {
Object result = super.remove();
System.out.println(this + ".remove() -> " + result);
return result;
}
public void clear() {
super.clear();
System.out.println(this + ".clear()");
}
public void reset() {
System.out.println(this + ".reset()");
}
}

/**
* Main class for testing this mixin framework.
*/

public class Mixin {
public static void main(String[] args) {
SizeOf s = new SizeOf(new Verbose(new Verbose(new Queue())));
s.insert("hello");
s.insert("world");
System.out.println(s.size()); // prints 2
s.clear();
System.out.println(s.size()); // prints 0
// note that we cannot invoke reset on s
// because SizeOf is not a subtype of Verbose
}
}

Bruce Chapman

Posts: 8
Nickname: chappy
Registered: Mar, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 25, 2005 5:36 PM
Reply to this message Reply
Although the syntax for java generics is similar to C++ templates, they are entirely different mechanisms, and many things that can be achieved with C++ templates is not possible with java generics.

So here's the question: is there some other way to perform something that produces this kind of mixin cleverness, or has erasure again foiled us?

Here is a mixins mechanism for Java using annotations and the apt tool. It does support generic mixins.

see https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/exploratory/mixin/package-summary.html

Eirik Maus

Posts: 15
Nickname: eirikma
Registered: Oct, 2005

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Oct 26, 2005 2:02 AM
Reply to this message Reply
This is what people solve with aspects.

Timestamp and Serial numbers are not normally part of the actual "business logic" of the class. They are only necessary to actually implement the business logic.

So, you implement serial numbering and timestamping in an aspect, and then you weave that aspect into the parts that need them in order to behave properly at compile-time or configuration-/load-time.

The same thing goes for other cross-cutting concerns like being transactional, logged, asynchronous etc. In my current project we introduce or wrap such stuff around the implementation classes so that the developers only have to see or care for the business logic.

It's easier that way.

Mohan Radhakrishnan

Posts: 7
Nickname: mindspace
Registered: Oct, 2005

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Nov 2, 2005 12:05 AM
Reply to this message Reply
Mixins are used to separate functional aspects from non-functional aspects. It is not a design flaw but one of the problems that OO cannot solve in a really reusable way. We should consider AspectJ or any such tool instead of tacking on everything to java.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Nov 2, 2005 12:52 PM
Reply to this message Reply
Here's another article that explores mixins and Java Generics:
http://www-128.ibm.com/developerworks/java/library/j-djc05133.html

William Pietri

Posts: 2
Nickname: wpietri
Registered: Nov, 2005

Might we see it in Java? Posted: Nov 5, 2005 4:14 PM
Reply to this message Reply
My toying with Ruby has been giving me some lanaguage envy lately, and so has chatting with friends who do serious work in Eiffel. I was glad to see this article, as it clearly discusses one of the precise things I am missing.

I know Java will never be Ruby, but I'd love it if someone more familiar with Sun's internal workings could talk about how much future versions of Java might make bold strides forward like 1.5 did. Will we ever be able to write something as developer-friendly as Rails without going as deep under the hood as, say, Hibernate does?

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Might we see it in Java? Posted: Nov 6, 2005 6:34 AM
Reply to this message Reply
I'm currently reading Bruce Tate's "Beyond Java" which addresses some of these issues. He's a little fast and loose in places, but it's thought-provoking nonetheless.

On more than one occasion when I've pointed out issues and what I percieve as shortcomings in the language, I've gotten the rather tautological answer "that's not Java." Or sometimes "Java is what it is, and you're asking for something that isn't Java," as if it leaped fully formed from the forehead of Gosling and there's nothing that can be done about it, so love it or leave it. I don't think this attitude has done the language a service for a long time; indeed, it took the fire lit by C# for J2SE5 to come about. Many of these new language features were ones that we were patiently told that we didn't really need -- until they appeared in C#. Now C# 3.0 is departing even further from Java, with things like type inference, and I doubt Java will go there.

There were plenty of papers and studies about Java mixins before J2SE5 came out, and nothing was included. It appears that mixins were something else that we "don't really need." So I wouldn't hold my breath for this one. Tate's attitude seems to be "it ain't gonna happen."

Mohan Radhakrishnan

Posts: 7
Nickname: mindspace
Registered: Oct, 2005

Re: Might we see it in Java? Posted: Nov 14, 2005 11:14 PM
Reply to this message Reply
Even Groovy is built with some AOP features like this http://jroller.com/page/mohanradhakrishnan/20051110

Thanks,
Mohan

Matt O'Connor

Posts: 1
Nickname: mocon
Registered: Jan, 2006

Re: Mixins: Something Else You Can't Do With Java Generics? Posted: Jan 2, 2006 9:30 PM
Reply to this message Reply
> Those appear to be what are called "Multimethods," which
> you can also find in the Nice language. But yes, another
> way to paste methods into an existing class. There seem to
> be a number of approaches to this, and I've never seen a
> comparison -- they tend to be expressed independently,
> without a sense of "what would mixins give you that
> multimethods wouldn't," etc.

No, multimethods dispatch on all arguments to the method. C# only allows dispatching on the first argument to the method; it's just providing a way to explicitly specify what the first argument is (outside of the defining class).

Flat View: This topic has 27 replies on 2 pages [ « | 1  2 ]
Topic: Introducing Neon Previous Topic   Next Topic Topic: Persistent Hash-Tables and Why Wikipedia Still Sucks at Computer Science

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use