Weblogs Forum - Traits for Java

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Traits for Java

20 replies on 2 pages. Most recent reply: Jun 11, 2010 10:33 PM by Howard Lovatt

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 20 replies on 2 pages [ « | 1 2 ]

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Traits for Java

Posted: Jan 29, 2008 3:39 PM

@qinxian,

If you forget the traits and just use interfaces

interface X { int m(); }
interface Y { int m(); }
class XY implements X, Y { // m imported twice, from X and Y
__public int m() { return 1; }
}

Then:

Y y = new XY();
y.m(); // returns 1

The fact that m comes from X or Y is not relevant. Same with traits, m can come from multiple sources:

interface X { int m() { return 1; } }
interface Y { int m() { return 2; } }
class XY implements X, Y { // m imported twice, from X and Y
__public int m() { return X.m(); }
}

Then:

Y y = new XY();
y.m(); // returns 1

There is only one m in XY whether you use traits or interfaces and therefore it does not matter whether the XY is an XY, X, or Y, there is still only one m. Just like Java behaves at present. The only twist is that the bodies in interfaces are inherited if there is no conflict and if they are not overridden.

qinxian xiang

Posts: 5
Nickname: moonlight
Registered: Dec, 2006

Re: Traits for Java

Posted: Jan 30, 2008 4:06 AM

Thank you very much.
@My last post, I think I should must first say I just newer for scala.
In deed I mean I hope multiple inheritance can be imported into java, at least to interface level.
Not remember name, A extension java do a refine thing,
class A + class B form.
In my old memory, Delphi do refinition on multiple interface conflicts by implementation keyword(maybe implement).
haa~, look at me blabla:)
I just feel the traits more like multiple inheritance.
So I say that at my last post.
Thank you again.
Regards

iirekm iirekm

Posts: 1
Nickname: iirekm
Registered: Sep, 2009

Re: Traits for Java

Posted: Sep 27, 2009 1:14 PM

I think we don't need any special Java syntax for traits or mixins.
A mixin in C++ may be implemented as template <typename T> class MyMixin: public T { new methods and overrides of methods from T }
class MyClass: public MyMixin1<MyMixin2<MyMixin3<Superclass>>> { ... }

Because in Java construct like "extends T" is impossible, instead of 'super' pseudovariable we have to create a 'super_' field to keep a reference to a 'super' object.
We instantiate mixins as new MyMixin1(new MyMixin2(new MyMixin3(new Superclass()))).
What we used here? Decorator or Adapter design patterns. The same can be achieved with TemplateMethod design patterns.

With traits the situation is even simpler. Because they don't have state, Singleton design pattern or 'static' methods are all we need, and MyClass (the class which 'glues' the traits) may look like:
class MyClass {
void method1() {
SomeTrait.method1(this);
}

void method2() {
SomeTrait.method2(this);
}
}

So to sum up:
- mixins = Decorator/Adapter patterns plus possibly some delegation, or TemplateMethod pattern
- traits = Singleton pattern or static methods plus some delegation

Adding trait or mixin support would be just only a small syntactic sugar, nothing more.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Traits for Java

Posted: Sep 28, 2009 5:35 AM

iirekm,

Sure it is just syntactic sugar to add traits to Java, e.g. the following trait example:

interface I { 
  String m1() { return "1"; }
  String m2() { return "2"; }
  // ... other methods
  String mN() { return "N"; }
}
 
class C implements I {}

could be written in current Java as:

interface I {
  String m1();
  String m2();
  // ... other methods
  String mN();
  final class Trait {
    public static String m1() { return "1"; }
    public static String m2() { return "2"; }
    // ... other methods
    public static String mN() { return "N"; }
  }
}
 
class C implements I {
  @Override public String m1() { return I.Trait.m1(); }
  @Override public String m2() { return I.Trait.m2(); }
  // ... other methods
  @Override public String mN() { return I.Trait.mN(); }
}

But as you can see adding traits saves some considerable boiler plate code and it catches errors in the boiler plate, e.g.:

1. The methods in I not having exactly the same signature, save for static, as the methods in I.Trait

2. The forwarding of the methods in C to the correct method in I.Trait

Further if traits were added to the language you could add a new method to an interface without breaking old code. EG I could add mZ() { return "Z"; } to I and would not need to recompile C since the linker, not compiler, would automatically add mZ() to C.

At present once you publish an interface you can't change it because you would break code that implements the interface. This problem of fixed interfaces leads to work arounds like helper classes containing static methods.

PS If you look at the original traits paper you will see that they show a C++ template version that is close to traits - I haven't directly commented on C++, since my C++ is rusty these days.

Tomas Mikula

Posts: 1
Nickname: tomas
Registered: Jun, 2010

Re: Traits for Java

Posted: Jun 7, 2010 10:00 AM

Hello Howard! I like the idea of having traits in Java. I add some of my thoughts.

What I see as the major advantage is that we would be able to compose complex classes from individual traits (and desired implementations of those traits). Using the List example, sorting is one trait, reversing the list would be another and shuffling yet another. For each of these traits there could be different implementations (quicksort, heapsort, mergesort, bubblesort, ...). The user may desire any combination of traits and their implementations. Here is how one could define two implementations of a sortable list: an array list with quicksort and a linked list with bubble sort.

interface SortableList<E> extends List<E> {
	public void sort();
}
 
interface QuickSortableList<E> extends SortableList<E> {
	@Override
	public void sort() {
		// implement quicksort on top of List methods
	}
}
 
interface BubbleSortableList<E> extends SortableList<E> {
	@Override
	public void sort() {
		// implement bubblesort on top of List methods
	}
}
 
class QuickSortableArrayList<E> extends ArrayList<E> implements QuickSortableList<E> {
	// no code except constructors needed
}
 
class BubbleSortableLinkedList<E> extends LinkedList<E> implements BubbleSortableList<E> {
	// no code except constructors needed
}

It would be even more flexible if there was some syntax for automatic definition of the "composite" class, i.e. no explicit definitions of QuickSortableArrayList and BubbleSortableLinkedList would be necessary. For example, like this:

SortableList<E> list1 = new ArrayList<E>{QuickSortableList<E>}();
SortableList<E> list2 = new LinkedList<E>{BubbleSortableList<E>}();

(In the braces is the list of traits to implement. Constructors are "inherited" from the superclass.)

To make traits even more usable, the same automatic class/interface generation could be supported in variable/field declaration.

List<E>{SortableList<E>, ShufflingList<E>} list = ...

Such synthetic class would be generated either at compile time or on its first use at runtime. An important property that should be guaranteed would be that a class with some traits would be assignable from a class that implements a superset of its traits, as in

List<E>{SortableList<E>, ShufflingList<E>} list1;
List<E>{SortableList<E>, ReversibleList<E>, ShufflingList<E>} list2 = ...;
list1 = list2;

(Not sure how feasible this would be to implement.)

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Traits for Java

Posted: Jun 11, 2010 10:33 PM

@Tomas,

All good suggestions. Scala does something similar to what you are suggesting.

I think the decision has been taken by Oracle to add virtual extension methods instead of Traits. There is a 'first draft' proposal here:

http://cr.openjdk.java.net/~darcy/DefenderMethods.pdf

They are similar to a trait, as I proposed, in many ways. However instead of allowing you to put the method body in the interface you name a static method to be called.

Cheers,

-- Howard.

Flat View: This topic has 20 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic


	Web Artima.com