Function types versus arrays

[Mikael Grev]

I tend to use arrays a lot, but almost exclusively with primitives. I do it for the speed and lesser memory consumption. When I have a collection of references to objects, i.e. when I'm not storing primitives, I almost exclusively use the collection classes. I have never encountered an ArrayStoreException to this date, obviously.

I do not think one would ever _need_ to store lambdas in arrays. I see no need since I estimate the relative performance and memory consumption winnings would be minimal.

Cheers,
Mikael


On Feb 8, 2010, at 20:30 PM, Alex Buckley wrote:

> Neal raises a fair point. I recognize that arrays of function types are 
> as potentially unsafe at runtime as arrays of non-wildcard parameterized 
> types.
> 
> And this is the same problem one sees when passing variables of 
> parameterized types as varargs parameters. The varargs method body can 
> silently do unsafe things, thanks to Object being a universal supertype.
> 
> Banning arrays of function types is an option. It somewhat conflicts 
> with Project Coin's promotion of [] syntax to read/write collections.
> 
> I am interested in people's thoughts on the limitations of arrays of 
> parameterized types. (Reification was not and is not an option, so 
> please no ranting about the stupid implications of erasure.) Does anyone 
> care about arrays anymore?
> 
> Alex
> 
> Rémi Forax wrote:
>> Le 07/02/2010 19:41, Neal Gafter a écrit :
>>> I've been asked if arrays and function types will play nicely
>>> together.  Specifically, for example, whether or not something like
>>> the following will be allowed:
>>> 
>>> #String(String)[] arrayOfFunction = new #String(String)[10];
>>> 
>>> The current draft spec, by the absence of any constraining rules,
>>> implies yes.  But if I have to guess, I would say the end result of
>>> project lambda will probably say no.  Although we haven't talked much
>>> about implementation techniques, I'm not aware of any proposed
>>> implementation technique that would allow this without opening a hole
>>> in the type system.
>>> 
>>> I don't know whether we should consider this important or not (I
>>> don't; I'm perfectly happy using java.util.List), but if it is
>>> important then someone should be thinking about what needs to happen
>>> (VM support?) to make it work.
>>> 
>> 
>> For the record the problem is:
>> 
>> #String(String)[] arrayOfFunction = new #String(String)[10];
>> Object[] array = arrayOfFunction;
>> array[0] = #int() (2);
>> 
>> The last line should raise an array store exception.
>> So the VM should be aware of the precise type of the array of function.
>> 
>> Currently, neither the anonymous class translation nor the method handle one
>> provide reified function type so array of function types are unsafe.
>> 
>> Because function type doesn't exist in the language, I propose to make 
>> the syntax
>> for an array of function type (#String(String)[]) illegal.
>> 
>> I'm also happy with List, perhaps we should introduce a new interface 
>> ReadOnlyList
>> which is a super type of List and array of objects but that another story.
>> 
>>> Cheers,
>>> Neal
>>> 
>> 
>> Rémi
>>