Stephan Koops wrote:
> Hello Paul, hello Bill,
>>>> I think it is useful to allow also Set and SortedSet. Sometimes the
>>>> order is irrelevant and/or dublicates could or should be ignored for
>>>> the app. I propose also to allow Collection.
>> What would be the order and dups policy when Collection is specified?
>> I don't think Collection should be allowed and the developer should be
>> explicit about the ordering/dups through the Java type specified.
> Doesn't matter, that means runtime environment is free to choose. If a
> method requires a Collection, there is never a order defined.
And dups?
> If a method (in general) want to be as flexible as possible, it should
> allows Collection. The idea was, to also allow this flexibility here.
>> If we are trying to keep things immutable then should arrays of stuff
>> should be allowed?
> We can avoid the modification on Collections, so we should do that. If
> we can't avoid this on arrays, doesn't matter ... (IMO)
> The argument for me for the arrays is, that they could be iterated and
> accessed very fast (compared to Lists).
The runtime bytecode compilers do a good job nowadays optimizing that
kind of stuff.
The use-case for me would be an EOU one if we think developers would
likely need to operate specifically on arrays e.g. if it is convenient
for such arrays need to be passed to other APIs.
Paul.
> But if someone needs speed, he
> should not use a specification, which requires a lot of using of
> reflections ...
> Bill, what do you say? You proposed the array.
>
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109