Function types versus arrays

[Zdenek Tronicek]

Another argument why to strive after arrays of function types is that
language should be intuitive. And if programmers can create arrays of any
type now (except generic arrays), they will, naturally, expect arrays of
function types. I think that exceptions in type system are evil.

To anticipate questions: I do not have any proposal how to do it and
I understand we are limited by the current type system (non-reified
generics) and JVM.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Joshua Bloch napsal(a):
> I just assumed that we'd do whatever it takes to make this works, up to
> and
> including VM changes. At least we don't have the migration compatibility
> issues that we had with generics. If arrays of functions don't work,
> functions are a second-class type family. That arrays and generics don't
> play nicely together is a major pain in the butt. I really would prefer
> not
> to see this repeated. I understand the difficulties in making this work
> but
> (as I keep saying) we shouldn't give up without a fight. Much as some of
> us
> consider arrays to be denigrated in favor of List<E>, they are still
> *widely
> *used, even in new code. If arrays of function types aren't supported,
> people will complain. And they may rightly accuse us of doing what was
> easy
> to implement rather than what is easy to use.
>
>     Regards from Cape Canaveral,
>
>     Josh
>
> On Mon, Feb 8, 2010 at 2:30 PM, Alex Buckley <Alex.Buckley at sun.com> 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
>> >
>>
>>
>
>