[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)
Adriano Ferreira
adriano.ferreira at me.com
Fri Jun 17 14:27:09 CDT 2016
+1 for consistency.
—A
> On Jun 17, 2016, at 12:04 PM, Patrick Pijnappel via swift-evolution <swift-evolution at swift.org> wrote:
>
> You could make the exact same arguments about `sin`.
>
> – What sin(x) should do is unambiguous, unlike array.filter { ... }.
> – There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().
> – The relevant metric of the strength of a term of art would be for how many users it already is a very much ingrained term (i.e. not how long it has been around). For sin() this is the case for pretty much anyone who has done high-school math. Conversely, map/filter/reduce will only be significantly ingrained for experienced users of languages that are functionally-centered enough to regularly use these, which is a much smaller percentage (though not insignificant).
>
> Let me turn your question around: What concrete benefits do we gain from modifying terms which are extremely widely recognized? It is not consistent, but is there any reason to believe that causes actual confusion? If not, then why fix what isn't broken?
>
> The benefits of renaming:
> – It makes learning easier as it establishes a consistent way to read Swift methods right from the start.
> – It would help users in intuitively learning consistent naming for their own methods, even if they haven't read the API guidelines.
> – It allows defining e.g. an in-place filter variant.
>
> I agree with your points on the problems with dropFirst/dropLast btw.
>
> On Fri, Jun 17, 2016 at 4:05 PM, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>> wrote:
> On 17.06.2016 15:58, Patrick Pijnappel wrote:
> I suggest to leave map+flatMap+reduce as-is as true terms-of-art
>
>
> Question still stands, what benefits do we gain from using the /exact/
> terms that are not present in the slightly modified ones?
>
> I don't know :-) I just see that many against renaming of map/filter/reduce/etc and suggest a compromise : we leave map/reduce as-is, but nothing else should be an exception to the naming rules.
>
>
> On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel
> <patrickpijnappel at gmail.com <mailto:patrickpijnappel at gmail.com> <mailto:patrickpijnappel at gmail.com <mailto:patrickpijnappel at gmail.com>>> wrote:
>
> `map`, `filter`, and `reduce` are *the* higher-order functions.
> Almost anything with any kind of block/lambda/closure feature
> supports them (I'm giving the side-eye to Foundation here), and all
> three names are backed by *very* strong conventions
>
>
>
> If `map`, `filter`, and `reduce` are not covered by the term-of-art
> rule, we might as well rename it to the sin()-and-Int rule, because
> I don't know what else it would cover. There is remarkable
> consistency in the naming of these operations across dozens of
> languages.
>
>
> The point the proposal raises is that the modified versions preserve
> the the terms of art in all the senses that matter (i.e. all the
> benefits like recognition etc. still apply).
>
> On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>
> <mailto:svabox at gmail.com <mailto:svabox at gmail.com>>> wrote:
>
> On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote:
>
> -1, for the same reasons stated on the thread. These are
> neither
> guaranteed to be mutating or non-mutating until you get to
> Collection.
> Changing map() to mapped() would be lying to the developer
> some of the
> time about the mutability of the interface.
> -DW
>
>
> Actually the -ed/-ing suffix is *not *intended to guarantee
> non-mutatability. It merely communicates whether it is a
> "return-a-transformed-version-of-the-instance"-type method as
> opposed to an
> in-place mutation. Clearly these are not in-place forms. Note
> that this is
> my interpretation of the intent of the guidelines (or what
> should be the
> intent) – if the core team agrees perhaps this deserves
> clarification in
> the document.
>
>
> Totally agree with you. I also understand this rule as separation
> of "in-place"/"returns transformed version". I.e. the suffix should
> say just "result of this operation will be returned and should be
> assigned to other instance variable". Otherwise, as I understand,
> ANY method that will touch or iterate the Sequence *could* mutate
> it and so potentially we should have no -ing/-ed methods for
> Sequence - no?
>
>
> These functions are different than for example `sort`
> because there
> can’t be a general mutating method of `map`. A variable of
> type `[A]`
> can’t be mutated to hold a `[B]` which would be the result
> of a map
> from `A -> B`.
>
>
> There could definitely be an in-place variant of filter. While
> a /fully/
> general method would not be possible for the others, an user might
> reasonable expect in-place variants of map/flatMap if T == U as
> with e.g. {
> $0 * 2 } or Optionals, and of dropFirst/dropLast if SubSequence
> == Sequence
> as with e.g. String.
>
> Also note that the -ed/-ing rule should not be merely for
> ambiguous cases,
> it should tell the user that the main use of the method is
> returning a
> transformed version of the instance. Having this be a rule you
> can depend
> on is important.
>
>
> +1
>
>
> -1 The Term of Art argument is very strong with these
> functions. I
> prefer them as-is.
>
>
> What specific benefits do we obtain from using the /exact
> /terms of art vs.
> the very slightly modified versions proposed?
>
>
> Although I believe we can leave map&reduce as-is, I can understand
> if we'll change them to mapped/reduced and will have consistent
> naming everywhere, don't think this will cause any confusion for
> one who will start to use them. In any case, we can add a hint in
> compiler like "did you mean 'mapped'?".
>
>
>
> On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via
> swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>> wrote:
>
> > The 'reduce()' at its core take an array of element and
> reduce it to single element (could be of a different type) as
> such it cannot ever be mutating (if one really want it, one
> could reduce an array to the same array but it is not the goal
> of the function). For this one it sound to me nearly like
> asking to rename 'max()' to 'maxed()', 'count' to 'counted' or
> implement a 'summed()' instead of a 'sum()' for [Int].
>
> `max`, `count`, and `sum` are all nouns—at least in the
> senses they are
> meant in those calls—so they do not take the -ed/-ing
> suffixes to form
> immutable variants. Instead, they would take the `form`
> prefix to form
> mutable variants, if they had them.
>
> `map`, `filter`, and `reduce`—at least in the senses they
> must be
> interpreted in for the names of those calls to make
> sense—are verbs,
> and so they *would* normally take -ed/-ing suffixes.
> However, as
> broadly-accepted terms of art, we have left them alone
> until now.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160617/e285bb21/attachment.html>
More information about the swift-evolution
mailing list