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

Thorsten Seitz tseitz42 at icloud.com
Mon Apr 4 00:49:05 CDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/d2a939b5/attachment.html>


More information about the swift-evolution mailing list