On Feb 10, 2014, at 3:11 PM, Jason Mehrens wrote:
>> Too bad there is no interface with only get(index), set(index, x),
>> and indexOf(x). Implementing only these would probably satisfy
>> all candidate usages.
>
> With default methods can't we modify the RandomAccess marker interface with
> h
> Too bad there is no interface with only get(index), set(index, x),
> and indexOf(x). Implementing only these would probably satisfy
> all candidate usages.
With default methods can't we modify the RandomAccess marker interface with
hostile implementations?
Jason
Wouldn't it be convenient, if negative indices were allowed for the
get() method here?
So that get(-1) would return the last element, like in some other
languages such as Perl or Python.
I understand it violates the spec for the List#get(), but this is the
'Double Ended' queue, so we may want
On 02/07/2014 01:59 PM, Martin Buchholz wrote:
ArrayDeque should implement most of the methods in List, notably get(i).
ArrayDeque should not actually implement List itself, because the change in
contract/behavior for hashCode/equals would be too great.
Right. My vague recollection is that th
On 02/07/2014 12:59 PM, Martin Buchholz wrote:
Sorry we're all such lamers.
??
ArrayDeque should implement most of the methods in List, notably get(i).
ArrayDeque should not actually implement List itself, because the change
in contract/behavior for hashCode/equals would be too great.
Exte
Just want to say that we've also had the need to implement an
array-backed Deque+List; we found no surprises implementing it and thus
I believe that extending ArrayDeque to implement List would be a
positive change. Failing that, a combined ArrayListAndDeque class seems
like a good idea.
I t
I noticed recently that the javac scanner is making use of ArrayList.remove(0)
when it consumes a buffer. Obviously this is an inefficient way to implement a
buffer, so I thought I'd try to fix it [1]. ArrayDeque seems to provide just
the behavior I need, with one fatal flaw: despite encoding
