On Thu, 13 Jun 2019 at 14:15, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> I like addFirst() and addLast() because these are the same kind of names as
> the existing java.util.List.add(int, E) which should be familiar to people.
>
> I feel that interpreting addFirst() as "add after first" breaks the
> principle of least surprise.
Huh? I think that is backwards.
I only said addFirst() *might perhaps* be interpreted that way, i.e.
it is potentially ambiguous.
Note that the existing add() method effectively means add AFTER, and
that is the general sense in which the word 'add' is used.
The 'principle of least surprise' cannot stop people from making a
incorrect interpretation.
However if there is a risk, then surely the principle means not
choosing the name?
I suggested prepend/append because I think they are unambiguous.
I won't object to addFirst/addLast but I'm not convinced it is the best choice.
The add() method should probably be deprecated whatever happens.
> Gary
>
> On Thu, Jun 13, 2019 at 9:03 AM Mark Dacek <m...@syberion.com> wrote:
>
> > addFirst is commonly used with LinkedLists. I wouldn't think it to be
> > unintuitive.
> >
> > On Thu, Jun 13, 2019 at 8:56 AM sebb <seb...@gmail.com> wrote:
> >
> > > On Thu, 13 Jun 2019 at 13:43, Gary Gregory <garydgreg...@gmail.com>
> > wrote:
> > > >
> > > > On Thu, Jun 13, 2019 at 8:32 AM sebb <seb...@gmail.com> wrote:
> > > >
> > > > > On Wed, 12 Jun 2019 at 22:11, Mark Dacek <m...@syberion.com> wrote:
> > > > > >
> > > > > > I’d support adding both.
> > > > >
> > > > > +1
> > > > >
> > > > > How about overloading as follows:
> > > > >
> > > > > ArrayUtils.add(T[], T, index)
> > > > >
> > > >
> > > > Ah, I see we already deprecated an "add at index" method in favor of
> > > > "insert at index":
> > > >
> > > > ...
> > > > * @deprecated this method has been superseded by {@link
> > #insert(int,
> > > > Object[], Object...) insert(int, T[], T...)} and
> > > > * may be removed in a future release. Please note the handling of
> > > > {@code null} input arrays differs
> > > > * in the new method: inserting {@code X} into a {@code null} array
> > > > results in {@code null} not {@code X}.
> > > > */
> > > > @Deprecated
> > > > public static <T> T[] add(final T[] array, final int index, final T
> > > > element) {
> > > > ...
> > > >
> > > > So the question becomes what should, ideally, be "add/insert first" and
> > > > "add/insert last" methods be called. We can then deprecate old APIs if
> > > > needed.
> > >
> > > Indeed.
> > >
> > > How about prepend/append ?
> > >
> > > I think the pair has an obvious and unambiguous meaning.
> > >
> > > Other languages use unshift/push, but unshift is not obvious, and
> > > there is already a shift (which is actually a partial rotate AFAICT).
> > >
> > > Also addFirst could just possibly be misread as 'add after first';
> > > similarly addLast could be misread as 'add before last'.
> > >
> > >
> > > > Gary
> > > >
> > > > >
> > > > > It seems inconsistent to have add() and addFirst(); that suggests
> > > > > there should be an addLast()
> > > > >
> > > > > > On Wed, Jun 12, 2019 at 5:09 PM James Carman <
> > > ja...@carmanconsulting.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I like it. Seems like a logical thing to do. Another idea would
> > > be
> > > > > adding
> > > > > > > at an arbitrary index.
> > > > > > >
> > > > > > > On Wed, Jun 12, 2019 at 5:04 PM Gary Gregory <
> > > garydgreg...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi All:
> > > > > > > >
> > > > > > > > We have org.apache.commons.lang3.ArrayUtils.add(T[], T).
> > > > > > > >
> > > > > > > > WDYT about adding a method that adds the element at the
> > > beginning of
> > > > > the
> > > > > > > > new array instead of the end?
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
