>
> Yes, because of the dual purpose of this method; 1) to ensure presence of
>> an element and, 2) answer whether the element already existed,
>>
>
> to be pedantic, answer if the element didn't already exist
>

Yes, #addNewElement: answers whether it was a new element.



> there isn't a clear and concise name which conveys the full nuance.  It's
>> one of those methods which requires an initial look at the comment and/or
>> code until one is familiar with it.
>>
>
> Given that addNewElement: doesn't convey the full nuance that's not a
> valid criticism of the other alternatives, is it ;-)
>

Well, I think it sort of does.  The word "add" means its compatible with
the Set's existing "add" -- we know it means it'll end up in the Set.  That
part of the name is stable.  Then there's that word, "New", which is the
part which conveys the special nature of the method.

We could either stick with that, find a new word, or use more than one
word.  But I think more words may not add clarity or save one from needing
to check the method implementation.


> I considered those names, too.  I didn't care for addIfAbsent: for the
>> reason you stated.  I don't care for ifAbsentAdd: because it's backward
>> with other "Absent" nomenclature in the API.
>>
>> And, I didn't go with #ifMissingAdd: because it confuses the return value
>> with the linguistic semantics -- e.g., if it returns true, does that mean
>> it was "absent" or that it was added?  forcing me to look at the method
>> implementation again anyway.
>>
>> #addNewElement: fits in with the #add... nomenclature part of the API,
>> being like a "command" to the object, to which it may answer, "no" (false),
>> if the element already existed.
>>
>> It seems the only initial confusion you had was whether it signaled an
>> Exception or not, but I see no other name that avoids the user needing to
>> look at the implementation at least the first time.
>>
>
> No.  The selector implies it might. The selector is bad because this does
> not add a new element, it ensures an element is present,
>

It is consistent with Set>>#add:.  I did consider #ensureNewElement:, but
that suffers from the implication you mention (that it might signal an
Exception) even more.  To me, the #add... prefix puts it in the same
neighborhood with the various Set>>#add: methods, and behaves accordingly.


> and answers if it was added.
>

Well, it answers if it was, indeed, a "New" element.


>
>> Therefore, I think #addNewElement: is a good name.
>>
>
> I beg to differ.  I find it misleading :-(  Which is a shame because it's
> really useful.  How about trying to reach consensus on a less misleading
> name?
>

Sure.  I'm not beholden to the name, but I don't know of a better one
that's both perfectly clear AND concise.

Best,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170615/8838e4dc/attachment-0001.html>