[swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Xiaodi Wu]

My read on the API guidelines is that the mutating/non-mutating distinction
is made by verbs vs. nouns. The verb itself doesn't have to "suggest" or
"feel" mutating, it just has to be clearly a verb. Thus, IMO, `form` is as
good a verb as any, although if we're going to return to bikeshedding I
would suggest that `do` is even shorter.

On Mon, Apr 4, 2016 at 1:20 AM Howard Lovatt via swift-evolution <
swift-evolution at swift.org> wrote:

> Looking at other languages:
>
>
>    1. A Java like API would be:
>       - mutating func remove(T) -> Void
>       - mutating func remove<S: SequenceType ...>(all: S) -> Void
>       - func removed(T) -> Self
>       - func removed<S...>(all: S) -> Self
>       - Similarly for retain and add
>       2. In Scala they primarily use operators, so a Scala like API would
>    be:
>       - func -=(inout Self, T) -> Void
>       - func -=<S: SequenceType ...>(inout Self, S) -> Void
>       - func -(T) -> Self
>       - func -<S...>(all: S) -> Self
>       - Similarly for & and +
>
>
> Either of these naming patterns seems better than those proposed :(.
>
>   -- Howard.
>
> On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I think Michel and Shawn did raise some good points here.
>>
>> -Thorsten
>>
>> Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution <
>> swift-evolution at swift.org>:
>>
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> > What is your evaluation of the proposal?
>>>
>>> I don't like "form" as a prefix. To me there is no difference between
>>> `union` and `formUnion`: both sounds functional-style, and actually the
>>> second one perhaps a bit more to my ears. There's basically two dictionary
>>> definitions of "form":
>>>
>>> 1. "bring together parts or combine to create (something)" which to me
>>> implies a new value is created, and
>>> 2. "make or fashion into a certain shape or form" which would imply that
>>> the material you start with is transformed, which is apparently the
>>> intended meaning and also the reverse meaning from the above.
>>>
>>> I mean, doesn't this make sense as an API?
>>>
>>>         let donut = baker.formDonut(dough) // non-mutating
>>>
>>> Perhaps instead of "form" we could use "become" as a prefix when the
>>> operation is naturally described by a noun. That would seem less ambiguous
>>> to me:
>>>
>>>         a.becomeUnion(b)
>>>         a.becomeIntersection(b)
>>>         a.becomeSuccessor(b)
>>>
>>> It's a bit passive, but I find it fits well when the operation is a noun.
>>>
>>> And there's no way the term lends itself to non-mutating cases without
>>> things becoming nonsensical:
>>>
>>>         let donut = baker.becomeDonut(dough) // non-mutating?
>>>
>>
>> I also am having difficulty coming to terms with the use of "form" (I am
>> a native English speaker). As you note "form" can imply the creation of
>> something from parts (more like assembling a new thing) as well as the
>> creation of something out of a material say a of block clay (more like
>> molding something out of an existing thing). It doesn't seem clear cut to
>> me to imply in place mutation.
>>
>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>> type of issue is generally true with any short word made up of the same set
>> of letters (made worse since "from" is more common in programming then
>> "form"). The mind quickly narrows in on a set of possible words given the
>> letters we see and then uses context to help get the correct one and/or
>> additional visual parsing to understand the exact ordering of letters (more
>> energy expended). Anyway since I keep seeing "from" instead of "form" I
>> keep going in the direction of thinking it returns something made from the
>> two (or more) items involved (not really sure why "from" goes that
>> direction in my head, it could also go the in place direction).
>>
>> I would prefer something other then "form" (note I just typed "from" by
>> mistake)... I think your suggestion of "become" has merit.
>>
>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
>> y.becomeIntersection(x) --reads to me as--> "y become intersection with
>> x"
>> y.formIntersection(x) --read to me as--> "y from oops... y forming an
>> intersection with x"
>>
>> In the "forming" situations it – to me – is ambiguous on if that is in
>> place or not. To me it implies more of giving something new back.
>>
>> I am -1 on "form" aspect of this proposal. ...of course things are
>> learnable as long as things are fairly consistent and not to far out of the
>> norm for typical language use. Personally I don't see "form" as that
>> typical in English.
>>
>> -Shawn
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/43ab0e50/attachment.html>