[SR-933] Rename flatten to flattened


(Anton Zhilin) #1

I've already expressed these concerns, but nobody noticed, apparently. Here
is it:

I think current -ed/-ing convention is ugly. It breaks syntactic
correctness, experience from other languages, mathematical notation and
functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make
anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this
change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?

- Anton


(Erica Sadun) #2

I would like to see a formal proposal along these lines. My other suggestions are here <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>.

-- E

···

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

I've already expressed these concerns, but nobody noticed, apparently. Here is it:

I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?


(Anton Zhilin) #3

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.
It's more a matter of what should be "default" in a specific domain.

In imperative domain, mutating version usually feels as the most natural
one.
Think `sort`. Everyone knows that sort must modify the array (usually
through a sequence of swaps) to be most efficient. (Heapsort is an
exception there, I guess.)
That's why it is mutating version should be the shorter one, and
non-mutating should have a prefix or a suffix.

In functional domain, non-mutating version usually feels as the most
natural one.
Think `filter`, `map`, `reduce`. This functions originated in functional
languages. Functional languages usually have immutability by default.
When we "map" these idioms to Swift, we should let non-mutating version be
the "default" one.
Of course, we can be strict with our own rules and inventive in terms of
function names, but we just shouldn't.

Think `union`, `intersection`. These terms originated from mathematics,
where mutability just doesn't exist.
Given such a domain area, it should be obvious that `union` on a set means
non-mutating version, unless stated otherwise.

So, I conclude that we should not enforce any guideline about naming
mutating/non-mutating versions of methods.
Correct me if this is a wrong conclusion.

- Anton

···

2016-04-15 19:31 GMT+03:00 Erica Sadun <erica@ericasadun.com>:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

I've already expressed these concerns, but nobody noticed, apparently.
Here is it:

I think current -ed/-ing convention is ugly. It breaks syntactic
correctness, experience from other languages, mathematical notation and
functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make
anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this
change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?

I would like to see a formal proposal along these lines. My other
suggestions are here
<http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>
.

-- E


(David Rönnqvist) #4

By “the big three”, are you referring to only the naming of map, filter, and reduce?

I would also like to see a formal proposal along these lines, and possibly more.

I also feel that the `inPlace` suffix was very clear (most important) and very much liked that it made the immutable version the default (less important). It manages to describe the distinction between `union`/`unionInPlace` and `sort`/`sortInPlace` in the name itself. To me, the `ed`/`ing` difference is much more subtle and favors people who are familiar with English grammar. One can argue that `sort` is both imperative and functional, and that because of [either side] the default should be [mutable/immutable]. Both arguments are valid.

- David

···

On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I've already expressed these concerns, but nobody noticed, apparently. Here is it:

I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?

I would like to see a formal proposal along these lines. My other suggestions are here <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #5

After hitting Send button, I remembered that "Enhanced floating-point
protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names
for mutating versions.
They should be non-mutating by default, as well as other purely
mathematical terms. I don't know how it can be unobvious.

- Anton

···

2016-04-15 23:36 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.
It's more a matter of what should be "default" in a specific domain.

In imperative domain, mutating version usually feels as the most natural
one.
Think `sort`. Everyone knows that sort must modify the array (usually
through a sequence of swaps) to be most efficient. (Heapsort is an
exception there, I guess.)
That's why it is mutating version should be the shorter one, and
non-mutating should have a prefix or a suffix.

In functional domain, non-mutating version usually feels as the most
natural one.
Think `filter`, `map`, `reduce`. This functions originated in functional
languages. Functional languages usually have immutability by default.
When we "map" these idioms to Swift, we should let non-mutating version be
the "default" one.
Of course, we can be strict with our own rules and inventive in terms of
function names, but we just shouldn't.

Think `union`, `intersection`. These terms originated from mathematics,
where mutability just doesn't exist.
Given such a domain area, it should be obvious that `union` on a set means
non-mutating version, unless stated otherwise.

So, I conclude that we should not enforce any guideline about naming
mutating/non-mutating versions of methods.
Correct me if this is a wrong conclusion.

- Anton

2016-04-15 19:31 GMT+03:00 Erica Sadun <erica@ericasadun.com>:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

I've already expressed these concerns, but nobody noticed, apparently.
Here is it:

I think current -ed/-ing convention is ugly. It breaks syntactic
correctness, experience from other languages, mathematical notation and
functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make
anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this
change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?

I would like to see a formal proposal along these lines. My other
suggestions are here
<http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>
.

-- E


(Patrick Smith) #6

Yes, I agree. I think in the guidelines should be a recommendation for mutating methods are preferred, when nonmutating are preferred, and when to have both. If performance is a key goal of Swift, so much that it influences API design, then some details should be part of the guidelines also.
Patrick

···

On Sat, Apr 16, 2016 at 3:56 AM -0700, "David Rönnqvist" <swift-evolution@swift.org> wrote:

By “the big three”, are you referring to only the naming of map, filter, and reduce?
I would also like to see a formal proposal along these lines, and possibly more.
I also feel that the `inPlace` suffix was very clear (most important) and very much liked that it made the immutable version the default (less important). It manages to describe the distinction between `union`/`unionInPlace` and `sort`/`sortInPlace` in the name itself. To me, the `ed`/`ing` difference is much more subtle and favors people who are familiar with English grammar. One can argue that `sort` is both imperative and functional, and that because of [either side] the default should be [mutable/immutable]. Both arguments are valid.
- David
On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
I've already expressed these concerns, but nobody noticed, apparently. Here is it:
I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?
I would like to see a formal proposal along these lines. My other suggestions are here.
-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #7

+1, almost totally agree.

IMO sort/map/filter/reduce/etc "belongs" to the functional word, as I can see Swift is moving to be more functional language, we like to use functional features like some.filter{}.map{}.reduce{}, we like such frameworks/libs like RxSwift/ReacriveCocoa, we are implementing Future<Result,Error> pattern, trying "Railway oriented programming" etc.
I think it is some kind of standard of naming for such functions and their behavior.

All this renaming is looking very strange for me, do we have more important things? IMO this is not normal, if we have "sort" as non-mutating in Swift2.0 (just like in other modern languages) but have "sort" as mutating in 3.0. Are we programming here or writing some poems etc? So we need all these "ing"/"ed"... Just can't understand and want some opinions from the community. Are you really support all this renaming?

But I extremely against "form" prefix : we will always read it as "from" : https://en.wikipedia.org/wiki/Typoglycemia

···

On 15.04.2016 23:36, Антон Жилин via swift-evolution wrote:

Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.
It's more a matter of what should be "default" in a specific domain.

In imperative domain, mutating version usually feels as the most natural one.
Think `sort`. Everyone knows that sort must modify the array (usually
through a sequence of swaps) to be most efficient. (Heapsort is an
exception there, I guess.)
That's why it is mutating version should be the shorter one, and
non-mutating should have a prefix or a suffix.

In functional domain, non-mutating version usually feels as the most
natural one.
Think `filter`, `map`, `reduce`. This functions originated in functional
languages. Functional languages usually have immutability by default.
When we "map" these idioms to Swift, we should let non-mutating version be
the "default" one.
Of course, we can be strict with our own rules and inventive in terms of
function names, but we just shouldn't.

Think `union`, `intersection`. These terms originated from mathematics,
where mutability just doesn't exist.
Given such a domain area, it should be obvious that `union` on a set means
non-mutating version, unless stated otherwise.

So, I conclude that we should not enforce any guideline about naming
mutating/non-mutating versions of methods.
Correct me if this is a wrong conclusion.

- Anton

2016-04-15 19:31 GMT+03:00 Erica Sadun <erica@ericasadun.com
<mailto:erica@ericasadun.com>>:

    On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    I've already expressed these concerns, but nobody noticed,
    apparently. Here is it:

    I think current -ed/-ing convention is ugly. It breaks syntactic
    correctness, experience from other languages, mathematical notation
    and functional idioms.

    `InPlace` suffix was so far more correct in these terms. We can make
    anything a convention, but should we?
    I liked the proposal about new naming conventions, but overlooked
    this change.

    Many people will agree with me. This still can be reviewed until Swift 3.
    If so, I will create a proposal to correct "the big three" in this.

    What do you think?

    I would like to see a formal proposal along these lines. My other
    suggestions are here
    <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/>.

    -- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #8

Yes, I agree. I think in the guidelines should be a recommendation for
mutating methods are preferred, when nonmutating are preferred, and
when to have both.

It would be interesting to see such a guideline. OK, off the cuff:

Having a nonmutating method available often means you can make more use
of let bindings and method chaining, so when you have a choice and it
suits a use case you can imagine, at least write a nonmutating method.
In addition, you may want a mutating form of a method when you'd
otherwise have to return a new instance of a heavyweight type.

···

on Sat Apr 16 2016, Patrick Smith <swift-evolution@swift.org> wrote:

If performance is a key goal of Swift, so much that it influences API
design, then some details should be part of the guidelines also.

Patrick

On Sat, Apr 16, 2016 at 3:56 AM -0700, "David Rönnqvist" > <swift-evolution@swift.org> wrote:

    By “the big three”, are you referring to only the naming of map, filter, and
    reduce?

    I would also like to see a formal proposal along these lines, and possibly
    more.

    I also feel that the `inPlace` suffix was very clear (most important) and
    very much liked that it made the immutable version the default (less
    important). It manages to describe the distinction between `union`/
    `unionInPlace` and `sort`/`sortInPlace` in the name itself. To me, the `ed`/
    `ing` difference is much more subtle and favors people who are familiar with
    English grammar. One can argue that `sort` is both imperative and
    functional, and that because of [either side] the default should be
    [mutable/immutable]. Both arguments are valid.

    - David

        On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

            On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution > <swift-evolution@swift.org> wrote:

            I've already expressed these concerns, but nobody noticed,
            apparently. Here is it:

            I think current -ed/-ing convention is ugly. It breaks syntactic
            correctness, experience from other languages, mathematical notation
            and functional idioms.

            `InPlace` suffix was so far more correct in these terms. We can make
            anything a convention, but should we?
            I liked the proposal about new naming conventions, but overlooked
            this change.

            Many people will agree with me. This still can be reviewed until
            Swift 3.
            If so, I will create a proposal to correct "the big three" in this.

            What do you think?

        I would like to see a formal proposal along these lines. My other
        suggestions are here.

        -- E

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org
        https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave