Skip to main content

mustang && multi-inheritance?

16 replies [Last post]
desnajpa2k5
Offline
Joined: 2005-03-27
Points: 0

does anybody know, if mustang (or jdk6) will contain multi inheritance?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
seanreilly
Offline
Joined: 2004-08-30
Points: 0

>
> My best example so far is a listener registration /
> event dispatcher.
>

I've got a little library working that nicely manages listener registration and event dispatching, using Java 5.0 language features.

https://events.dev.java.net/

The project is still pending approval, so I'm not sure if you'll be able to see it. If not, send me an email and I'll arrange to get the source code to you another way.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

Sean,

No I can't see that project.

I know the code is pretty simple, but I'd be interested to see how you handle it.

Could you either grant me observer status on your project (should work but might not if the project isn't approved yet), or email it to me brucechapman@dev.java.net

Ta.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

> You don't need it.

Actually you dont NEED anything more than machine code, and a toggle switch for each bit in a word, and a toggle switch for each bit in an address, and a push button to write the toggled data into the toggled address.

However, most of us have found abstractions of this basic programming mechanism that allow us to work closer to the problem domain, rather than the solution domain.

Mixins is one of these mechanisms. And like all the others it is not appropriate to every situation. And like all the others it can't do everything. That does not detract from its usefulness in those situations for which it was designed.

wir33658
Offline
Joined: 2004-08-22
Points: 0

I hope that will never happen, because you whould run into the same problems as in C++. So, multiple inheritance of interface is great, but not on classes. You don't need it.

fedork
Offline
Joined: 2004-03-24
Points: 0

Actually I would think it would be useful, and would still avoid all the problems if multiple inheritance _is_ allowed as long as each method is only implemented by one of the superclasses. If you try to extend to classes implementing same method it's a compile-time error. This would be useful in most cases - s.a. having many classes which already extend various superclasses also extend some one-method listener/handler/etc... Right now in such cases you have to resort to copy-and-pasting....

And I think disallowing multiple inheritance of _implementations_ removes all the problems.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

The experimental rapt mixin facility allows you to rename the methods during the mixing process in order to avoid method signature conflicts.

For example, here is a mixin[code] @RenamableImplementation(EventDispatcherImpl.class)
interface EventDispatcher extends Mixin {
@RenameRule(prefix="add", suffix="Listener")
public void addXXXListener(L listener);
@RenameRule(prefix="remove", suffix="Listener")
public void removeXXXListener(L listener);

/**
returns a proxy instance of L which fans out any method
call, to each of the registered listeners
*/
@renameRule(prefix="foreach", suffix="Listener")
@Protected
public L foreachXXXListener();
}[/code]
To use this twice you do this
[code]
@Mix(base=Object.class,
add={
@Flavor(value=EventDispatcher.class, name="widget")
@Flavor(value=EventDispatcher.class, name="foo")
})
class MyClass extends MyClassSuper implements
Sux2,EventDispatcher> {}[/code][b]Note:[/b] Sux2 is just an array of type literals which are the actual values used for any .class literals in the Mix or Flavor annotations that need type parameters. There is also Sux1 which takes 1 type literal etc up to Sux15

Apt generates the following class when it compiles MyClass[code]class MyClassSuper extends Object {
private EventDispatcher widget = new EventDispatcherImpl();
public void addWidgetListener(WidgetListener w) {
widget.addXXXListener(w);
}
public void removeWidgetListener(WidgetListener w) {
widget.removeXXXListener(w);
}
protected WidgetListener foreachWidgetListener() {
return widget.foreachXXXListener();
}
private EventDispatcher foo = new EventDispatcherImpl();
public void addFooListener(FooListener w) {
foo.addXXXListener(w);
}
public void removeFooListener(FooListener w) {
foo.removeXXXListener(w); }
protected FooListener foreachFooListener() {
return foo.foreachXXXListener();
}
}[/code]Thereby avoiding the naming clash.
(note some details have been omitted above, they don't help to illustrate the renaming mechanism)

peterkessler
Offline
Joined: 2004-10-27
Points: 0


mustang will be defined as [code] public static final boolean mustang = false;[/code] so in
[code] mustang && multi-inheritance[/code]we won't even have to think about evaluating multi-inheritance.

The Java programming language already supports multiple [b]interface[/b] inheritance. We are not planning on adding multiple [b]implementation[/b] inheritance to Mustang (or [i]any[/i] future release, as far as I know).

jhannes
Offline
Joined: 2004-10-04
Points: 0

Hmmm... mustang is false? That is rather sad.

Anyway, it would all of us a lot if we could get mixins. Lots of the more uses for both multiple implementation inheritance and AOP can be easily replaced by mixins.

~Johannes

brucechapman
Offline
Joined: 2004-03-18
Points: 0

Mixins.

Its about 1 week away, all things going to plan.

Tiger has enough features to make mixins feasible.

I have it working when the input is correct, but some of the error reporting is still a bit cruddy, and the implementation has drifted away from the javadocs I initially wrote, so the doc comments need a bit more tweaking.

I'll let you all know here when its posted, or if you want to be one of the first to know, register as an observer on the rapt project http://rapt.dev.java.net/

Oh, and I'm also writing more documentation, so if anyone (Johannes in particular) has some realistic uses for mixins that will strike an immediate chord with your average java programmer, can you let me know. I have some examples but most are a little (or a lot) contrived.

My best example so far is a listener registration / event dispatcher. Adding Undoable to a text property is OK but slightly contrived. Adding bean properties via a mixin mechanism is probably suboptimal (performance) for most people, but can be done with 1 line.

Others ?

Bruce

jhannes
Offline
Joined: 2004-10-04
Points: 0

Great news, Bruce.

The main reason I focus on mixins is that I see how many of the introduction uses of AOP are better handled by mixins. This is a good area to go for examples.

As far as real-live examples are concerned, I will try to provide them I discover them. Here is a sampling of what springs to my mind immediately:

The most pressing example we have now is that of a HistoricalObject (the name is not perfect). Any domain object can be a historical object, and the historical object is responsible for tracking progress through processing steps. This is code we plan to implement through aspects, but then all the object that are targeted by these aspects will have to implement the same functionality in that interface.

Object validation is another where we have experienced a lot of code shared between class hierarchies. Stuff like checkNotNull().

For tests: Assert-functionality and test-data functionality.

We also have some need of sharing code between otherwise unrelated objects in order to support access control and billing: Any object subject to these requirments must have an owner. I am not sure that there will be enough code to warrant mixins here, though.

~Johannes

brucechapman
Offline
Joined: 2004-03-18
Points: 0

Johannes,

thanks for those ideas.

HistoricalObject looks interesting. What methods do you envisage in a simple implementation? I am imagining you have an enum of stages (or steps), and HistoricalObject has a set method to set the stage, with some checking to make sure it is a valid stage wrt workflow etc. Yes?

checkNotNull is probably handled cleaner as a static method in a helper class, with possibly a static import if you want to call it often. That would be even simpler than mixing the methods into your class. Some people have a theoretical aversion to static import, but I think this is a case where static import could reasonably be used.

Access control is an example that I have seen in papers on mixins. But those particular examples don't map well into java, they are probably solving language domain rather than application domain issues.

I'll try and find a more java relevant problem to solve in this space. Unless you want to elaborate a little on your requirements, but I realise that is hard if you can't see how my mixins are working.

thanks

Bruce

jhannes
Offline
Joined: 2004-10-04
Points: 0

HistoricalObject will have a list of states that the object has been in, a current state, and a method to update the state. It will probably not check the state transition itself - this will be done in domain specific code. The state will as you suggest be an enum.

I agree that static import can a replacement for some of the examples I use of mixins. Maybe a counter-example could be that we might want checkNotNull to include the Id of the object which checks (maybe getId() is another mixin, but I am thinking it might as well be an interface).

The access control is hard to get into into much detail without explaining and disclosing a lot of details.

~Johannes

desnajpa2k5
Offline
Joined: 2005-03-27
Points: 0

...pointers? is jdk6 gonna change into c++?

kirillcool
Offline
Joined: 2004-11-17
Points: 0

Yep. Sun figured out that it's what people want. This, of course, opens up some nice possibilities - think about getting a pointer to float and treating it as integer. You'll be able to get access to the internal representation of floats. Not that it would matter, as the internal representation will be different in various platforms.

zander
Offline
Joined: 2003-06-13
Points: 0

krillcool; you forgot the best new feature! The new release will make JNI soo easy that you can open any c/C++ library without any extra native code, finally making the list of libraries available for Java just as big as any other language out there.

kirillcool
Offline
Joined: 2004-11-17
Points: 0

It will. It also will feature operator overloading and precompiler directives. In addition, the underlying hardware support will not guarantee the same number of bits for the same type on different platforms, and you will be able to play with pointers.
They are not quite sure about the name, the lawyers are still working out the legal details with some Danish people from Aarhus, but once that is over, you'll know.