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 < [email protected]> 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 < > [email protected]> 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 < >> [email protected]>: >> >> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution < >> [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
