Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: change getFromFirst to return non-optional #606

Open
jvasileff opened this issue Dec 15, 2014 · 1 comment
Open

Proposal: change getFromFirst to return non-optional #606

jvasileff opened this issue Dec 15, 2014 · 1 comment
Milestone

Comments

@jvasileff
Copy link
Member

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.
@FroMage FroMage modified the milestone: 1.1.5 Jan 9, 2015
@quintesse
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants