You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wasn't sure how to make this proposal, since at the face of it, it seems un-Ceylon like. But I think it is worth consideration.
Currently, Array.getFromFirst(index) returns Element?. My contention, however, is that the normal use case is for it to be immediately followed by an assertion that the return value exists (when Element satisfies Object, of course). And, therefore, getFromFirst and getFromLast should return Element, with an AssertionError for invalid indexes.
Unlike keys for maps and sets, array indexes are not usually identifiers for the stored elements; their use as identifiers is usually relevant only in terms of the array itself. So, when attempting array.getFromFirst(10), you probably expect the call to succeed. The value 10 is likely to have come from something like a variable used for iteration, or maybe the result of a find method, rather than something unrelated to the structure of the list, like an employee id.
The properties first and last are of course very different, and will often be used without the knowledge of whether the array is empty or not.
So I think there are a few reasons and justifications for this change:
Optimize for the normal use case; eliminate unnecessary assertions
Make List.getFromFirst symmetric with ListMutator.set in terms of throwing an AssertionError on index out of bounds.
The get(Key) method would still be available, for when Element? is preferred.
I suspect there would be minimal impact to existing code. Idiomatic Ceylon avoids explicit access by index except in special circumstances.
Incidentally, but importantly, I believe this change may be necessary for potential support of specialized get methods for Array<primitive>s.
In an attempt to be objective, a few counter points:
Returning Element? may be of use when processing corresponding elements of two or more arrays of different sizes, where default values may be used for missing elements.
I suppose you may know in advance that an array should store exactly 100 elements, but as an optimization, you may wish to start with a smaller array and expand it if necessary, and for whatever reason, rely on an exists test on the return value of getFromFirst to determine the current size. But, really, there are better ways to accomplish this.
I have been focussing on Array, but getFromFirst is actually defined by Iterable, where arguably the current behavior is more valuable since checking the size of Iterables can be expensive. I'm not sure what the use case is, but if it's important, perhaps getFromFirstElse(index, fallback) could be defined. Or, just use iterable.skip(index).first.
The text was updated successfully, but these errors were encountered:
The other idea was, I think, to add a different method for that, something like unsafeGet() and/or unsafeGetFromFirst(). But if this issue is specifically meant for Array maybe my proposal #612 to extend the idea we use for Sequences when dealing with emptiness would help here as well?
I wasn't sure how to make this proposal, since at the face of it, it seems un-Ceylon like. But I think it is worth consideration.
Currently,
Array.getFromFirst(index)
returnsElement?
. My contention, however, is that the normal use case is for it to be immediately followed by an assertion that the return value exists (when Element satisfies Object, of course). And, therefore,getFromFirst
andgetFromLast
should returnElement
, with anAssertionError
for invalid indexes.Unlike keys for maps and sets, array indexes are not usually identifiers for the stored elements; their use as identifiers is usually relevant only in terms of the array itself. So, when attempting
array.getFromFirst(10)
, you probably expect the call to succeed. The value10
is likely to have come from something like a variable used for iteration, or maybe the result of a find method, rather than something unrelated to the structure of the list, like an employee id.The properties
first
andlast
are of course very different, and will often be used without the knowledge of whether the array is empty or not.So I think there are a few reasons and justifications for this change:
List.getFromFirst
symmetric withListMutator.set
in terms of throwing anAssertionError
on index out of bounds.get(Key)
method would still be available, for whenElement?
is preferred.Array<primitive>
s.In an attempt to be objective, a few counter points:
Element?
may be of use when processing corresponding elements of two or more arrays of different sizes, where default values may be used for missing elements.getFromFirst
to determine the current size. But, really, there are better ways to accomplish this.Array
, butgetFromFirst
is actually defined byIterable
, where arguably the current behavior is more valuable since checking the size ofIterable
s can be expensive. I'm not sure what the use case is, but if it's important, perhapsgetFromFirstElse(index, fallback)
could be defined. Or, just useiterable.skip(index).first
.The text was updated successfully, but these errors were encountered: