A syntax option (function types versus arrays)

Howard Lovatt howard.lovatt at gmail.com
Thu Mar 11 14:58:30 PST 2010


I am not sure it does preclude the JVM from optimizing the instance
creation, some JVMs do currently optimize away object allocation when
they can. To me this is another possible optimization.

There is an advantage in spelling out that you have an expensive
operation in that people are more likely to be aware of a potential
problem and hence avoid it in the first place, e.g.:

for ( final int[] row : matrix ) {
  filteredAddAll( result, row, new #< boolean( final int x ) >( x % 2 == 0) );
}

Is likely to be spotted by the programmer because of the new and
therefore they are likely to refactor it themselves:

final #< boolean( int ) > even = new #< boolean( final int x ) >( x % 2 == 0);
for ( final int[] row : matrix ) {
  filteredAddAll( result, row, even );
}

Which is nice, since people are then understanding what is actually happening.

On 11 March 2010 19:09, Alex Blewitt <alex.blewitt at gmail.com> wrote:
> On 11 Mar 2010, at 07:50, Gernot Neppert wrote:
>
>>>
>>> A possible alternate syntax is:
>>>
>>> #< R( A ) throws E > example = new #< R( A a ) throws E >( ... );
>>
>> I like the following two things about this syntax:
>>
>> firstly, the use of "new" to create a lambda. This makes it consistent
>> with other object instantiations (in this case, an object of function
>> type being created).
>
> However, it precludes the compiler from being able to optimise out instance creation in the case that the lambda is constant (or doesn't capture/use local state) since 'new' is defined semantically and by general understanding to create a new instance every time.
>
> What you really need is some kind of 'factory' that can either return you the same instance or give you a fresh instance each time depending on the circumstances. Enforcing an always-creation model would be a significant disadvantage for the kinds of filters (like 'even') which would not change each time.
>
> Alex



-- 
  -- Howard.


More information about the lambda-dev mailing list