m.invoke() vs. m()

[Osvaldo Doederlein]

2009/12/7 Reinier Zwitserloot <reinier at zwitserloot.com>

> On Mon, Dec 7, 2009 at 11:46 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:
>
>> compiled/executed as method invocation. But either way it's irrelevant
>> because we can just overload the "()" operator to handle both method-call
>> and closure-call, there's much worse precedent for that in Java (e.g. "+").
>>
>>
> "Java already sucks worse in regards X in area Y" is not an excuse to pile
> on the hurt.
>

By "worse" I meant "bigger"; I don't think that the overloaded "+" operator
sucks a single bit. ;-) The fact is that the language already has many cases
of superficial ambiguity, and they are NOT a problem. In fact the only
"unambiguous" languages I programmed were Assembly - and these were
old-school ASMs without powerful macros or the bewildering ISAs of modern
chips.


>
> This problem, as well as others I can think, seem strawmen to me.
>>
>
> How is that strawman? Do you think that people in practice never change the
> types of variables, or that with closures, existing variables of SAM types
> won't be rewritten to closure types? That seems quite a stretch.
>

Yes people do these things and many others, there's a ton of ways to break
backwards compatibility, see Vladimir's reply too. I doesn't matter that
much, unless you picture unexperienced programmers posing as APIs designers
- but these guys will shoot themselves in the foot no matter how much
baby-sitting we provide in the language. Designing good APIs that can evolve
well is extremely hard, and most of the difficulty does not lie in language
syntax.

On your last comments below: invoke-less calls would be just sugar for the
explicit calls; if you want .invoke for any reason (language interop,
reflection, disambiguation) you use it. Java already has similar examples.
You can iterate over a collection with explicit .iterator(), .hasNext() and
.next() calls, or you can use enhanced-for. I don't remember anyone
complaining that this made the language more complex, or that "the
abstraction leaked".

A+
Osvaldo


>
> [snip rant on reflection]
>>
>
> How is this in any way or form relevant to the presumed added complexity of
> '.invoke'? You're comparing the need to insert a gajillion casts and catch 4
> separate exception types on every reflection call with adding the letters
> ".invoke" to invoking closures? That also seems quite a stretch.
>
> ".invoke" does not suffer from any added complexity for users; it's
> considerably simpler. Closures are represented at the system level as an
> object. The payload of this closure is represented as a method (named
> "invoke", as being compatible with other JVM languages is a good thing).
> There's no way to abstract this away without that abstraction leaking like a
> sieve. Closures will of course extend Object, meaning you can do the usual
> things to them, such as reflection. Which will at the very least have to
> reveal that invoke method. I haven't seen a proposal to get rid of this, and
> I doubt a good one exists, so, whatever complexity you think exists in
> having a closure payload exist as a method named "invoke" cannot be avoided.
>
> Thus, we have two choices.
>
> (A) .invoke is the only way to invoke a closure, and we get all the
> complexity (insofar as it exists) of abstracting closures as a method named
> "invoke" on some function type,
>
> or
>
> (B) we allow .invoke, *AND* we allow invoke-less straight parameter syntax.
> Now we get all the complexity of A, and in addition, we get all the
> complexity of B, including fields that occupy more or less namespaces
> depending on their type, for example.
>
> Clearly, choice B cannot possibly be less complex than choice A.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091207/f866d66d/attachment.html