I've used this technique in some projects (internal APIs), with some degree
of success, but I don't think it fits well in this case.
Java's generics doesn't support this very well. It makes the code too
verbose, and in some inheritance cases, it just doesn't work.
One feature I would love to see in Java (although I have no hope to ever
have it) is something like this:
class A {
public this add(Component c) {
if (c == null)
return; // 'this' is implicit, just like 'void'
components.add(c);
// 'return this;' is implicit, just like 'void'
}
}
class B extends A {}
A a = new A().add(comp);
B b = new B().add(comp); //since 'this' is always implicit (so, cannot be
overridden), the compiler would know that the return type is B, not A
method chaining paradise! :)
On Mon, Aug 29, 2011 at 11:11 PM, richard emberson <
[email protected]> wrote:
> For many months the Scala port of Wicket 1.5 has used self type
> return values (this.type) where appropriate; more than 10 methods
> in Component, more than 5 in MarkupContainer, etc. with all
> tests passing and some code simplification (or, at least, the
> removal of some casts). Ought to work in Java also.
>
> Richard
>
>
> On 08/29/2011 06:52 PM, Martin Makundi wrote:
>
>> Hi!
>>
>> Is wicket using self type yet for methods like add(cc) {...; return this;
>> } ?
>>
>> http://calliopesounds.**blogspot.com/2010/11/having-**
>> java-generic-class-return-**type.html<http://calliopesounds.blogspot.com/2010/11/having-java-generic-class-return-type.html>
>>
>> **
>> Martin
>>
>>
> --
> Quis custodiet ipsos custodes
>
