Re: Re: Curious about method handling

On Saturday 06 Aug 2005 13:45, Artem Gr wrote:
> In fact, i think, the statement "b.c == b.c()" will remain in the
> language as a part of "accessor method" syntax. I think it is currently
> underdeveloped (no clear way of substituting accessor methods; presence
> of different get* set* accessor methods; unclear interference with
> on-the-way visibility system) or just isn't documented well. Replacing
> it with a closure (anonymous method) syntactic sugar doesn't seem an
> obvious decision to me. It might be possible, though, to implement such
> behaviour when a method is expected, and "b.c" doesn't return one; that
> is, when we expect a value, "b.c" is used as an accessor to a "virtual"
> field "c", and we expect a method, "b.c" is used as a closure.

That makes sense. Although I think I prefer Ruby's method of handling 
accessors (where one can overload an operator for a method, as well as a 
class) in theory, that wouldn't be easy (or perhaps even possible) to tie in 
with the current Java libraries.
 
> Nevertheless, i don't see much benefit in this, since "()=>b.c" syntax
> is sufficiently convenient and is much clearer about what it does.

That's a point; I didn't realise that you could do this:

printOutput( () => a.b() );

instead of:

printOutput( () => { return a.b() } );

That's certainly close enough to the hypothetical "a.b" syntax not to make too 
much of a difference, practically speaking.

Okay. That's more or less answered all my questions :). The future accessor 
method syntax seems more useful than the relatively small advantages one 
would get from the hypothetical syntax changes I suggested.

--
James Reeves
http://www.monkeyengines.co.uk/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf