[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)
Vladimir.S
svabox at gmail.com
Fri Jun 17 09:05:07 CDT 2016
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>> 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>> 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>>> 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>>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
More information about the swift-evolution
mailing list