Now this is an interesting idea...
(Get it? "...*this* is an interesting idea"?)
Does "This" mean an object of the same class, or the literal "this" object?
For instance, is this
legal?
public class Foo {
public This someMethod() { return new Foo(); }
}
~~ Robert.
JodaStephen wrote:
> The 'self type' proposal for Java is what is needed here, not method
> chaining:
>
> public class Base {
> public This setBaseStuff() { /* ... */ return this; }
> }
> public class Sub extends Base {
> public This setSubStuff() { /* ... */ return this; }
> }
>
> The 'This' (or 'this') used as a return type means the actual type of
> the instance, enabling situations like this to work.
>
> Method chaining is very hard to follow (and I oppose it), as everyone
> has already learnt the rule that you can't invoke a method on a void.
>
> Stephen
>
>
> On Feb 14, 4:14 am, Jeff Grigg <[email protected]> wrote:
>> After listening to recent episodes, I've been working my way back to
>> earlier episodes, and I keep tripping over discussions of Matthias
>> Ernst's "Chaining: A Modest Language Proposal" -- which would make the
>> compiler enable a method chaining / "fluid interface" convention on
>> methods returning the void type.
>>
>> I'm also somewhat bothered by the idea of reinterpreting void return
>> types, but I think it will be helpful to consider the cases where
>> usage would be simplified or fixed by his proposal. So I posted two
>> code examples on my blog:
>>
>> http://jeffgrigg.wordpress.com/2009/02/14/method-chaining-good-for-java/
>>
>> Briefly, given these two "Builder" classes:
>> public class Base {
>> public Base setBaseStuff() { /* ... */ return this; }
>> }
>> public class Sub extends Base {
>> public Sub setSubStuff() { /* ... */ return this; }
>> }
>> This code works:
>> new Sub().setSubStuff().setBaseStuff();
>> But this code doesn't compile:
>> new Sub().setBaseStuff().setSubStuff();
>>
>> The problem is that when you use method chaining on classes that
>> extend other classes and which add methods, you MUST always call
>> subclass methods before calling superclass methods -- otherwise it
>> won't compile. In non-trivial examples, it gets harder and harder for
>> the class' users to follow these rules.
> >
>
--
~~ Robert Fischer.
Grails Training http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
