+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 <[email protected]
<mailto:[email protected]>>:
On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
