Method calls vs lambda calls

[Neal Gafter]

This is a more general problem of the shorthand syntax being or not being
available in subtypes of function types.  If we have

class C implements #int(int) { ... }
C c;

Can we use the shorthand c(4)?

Cheers,
Neal

On Thu, Dec 17, 2009 at 1:22 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> Yes that is a forth option; but it is confusing because people expect
> generic types to behave like concrete types (that's the point of
> generics). Anomalous behavior of generics, e.g. interaction with
> arrays, is already a problem and this option will only increase the
> problems. For example the following would work with the option I
> listed as 2, but not with this fourth option:
>
> class Base<T> { T t; }
> class Reasonable extends Base<List<Integer>> {
>  { t = new ArrayList<Integer>(); }
>  void reasonable() { t.add( 1 ); }
> }
> class Unreasonable extends Base<#int()> {
>  { t = #int() (42); }
>  void unreasonable() { out.println( t(); } // Error, T is not
> behaving as a #int()
> }
>
> If in reasonable() I can treat T as a List, why in unreasonable()
> can't I treat T as a #int()? (Ok in some circumstances I can treat T
> as a #int(), but not in all.)
>
>  -- Howard.
>
> 2009/12/17 Neal Gafter <neal at gafter.com>:
> > On Thu, Dec 17, 2009 at 12:02 AM, Howard Lovatt <howard.lovatt at iee.org>
> > wrote:
> >>
> >> Based on Neal's generic example, here is a particularly nasty case:
> >>
> >> class Base<T> {
> >>  T t;
> >>  T t1;
> >>  void t() { out.println( t ); }
> >> }
> >>
> >> class Derived extends Base<#int()> {
> >>  {
> >>    t = #int() (42); // Can't override t() because it has a different
> >> signature
> >>    t1 = #int() (41);
> >>  }
> >>  void test() {
> >>    out.println( t1 ); // Prints Function_intATXXX
> >>    out.println( t1() ); // Would be nice if this printed 41
> >>    out.println( t ); // Prints Function_intATXXX
> >>    out.println( t() ); // Error t() returns void
> >>  }
> >> }
> >> ...
> >> Can anyone think of any other options?
> >
> > Yes: a variable is added to the method namespace only when declared with
> a
> > function type.  In this example, t and t1 are not declared with a
> function
> > type, but rather are declared with the type of a type parameter (T).
> > Therefore shorthand invocation is not available for them.
> >
> > This is a nice solution because it prevents names being inherited into a
> > namespace in which they did not previously appear.
> >
> > Cheers,
> > Neal
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
>