On 13 Dec 2015, at 10:48, ilya <ilya.nikokoshev@gmail.com > <javascript:_e(%7B%7D,'cvml','ilya.nikokoshev@gmail.com');>> wrote:
> but they make code editing easier at the expense of readability.
Disagree. This really depends on the example. E.g. which is more readable:
On Sun, Dec 13, 2015 at 12:40 PM, David Hart <david@hartbit.com > <javascript:_e(%7B%7D,'cvml','david@hartbit.com');>> wrote:
Hi Ilya,
Why use a style guide when the language can enforce rules to eliminate
the ambiguity?
On the other hand, it allows a logical explanation of how you can take
code from global scope and put it into an instance scope
This helps implementing patterns like "take a long function and make it
into a struct with a bunch of small functions instead".
Both of your previous points make sense but they make code editing easier
at the expense of readability. For me, readability has always been more
important, as we spend most of our time reading than writing code.
That's why I suggest using .x and .f() to mark implicit self.
I agree that that would potentially add confusion to the grammar. I've
always liked the @ and @@ prefixes of Ruby for accessing instance and class
properties, but I agree that symbols like that would feel a bit foreign in
Swift.
David
On 13 Dec 2015, at 10:16, ilya via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
> But implicit self is confusing in a lot of code
On the other hand, it allows a logical explanation of how you can take
code from global scope and put it into an instance scope:
let greeting = "Hello"
let name = "Michael"
func greet() {
print("\(greeting), \(name)")
}
seemlessly becomes
class Greeter {
let greeting = "Hello"
let name = "Michael"
func greet() {
print("\(greeting), \(name)")
}
}
> can (and does) lead to shadowing bugs,
There are simple strategies that help to minimize the amount of
shadowing, e.g.
- only expose the minimum necessary amount of names in any scope
- break functions into small part so that it's easy to see all the local
name declarations
- not use any globals, or at least name them in a visually different way
(UppercaseCamelStyle)
- name properties and locals in a different way (classProperty, local_var)
Even without a formal code style, if you tend to make property names
longer and local names shorter, your risk of shadowing goes down.
> .x and .f() to mark implicit self. I realize that this may conflict
with enum usage.
This will lead to a lot of ambiguity:
func f() {
let x = NSOperation()
.name = "Name" // is it x.name or self.name??
...
}
> If so, then use another marker. For instance :x or ^x or anything.
This is workable, but still I think this is one of the best points of
Swift – the existence of instance scope where names are simply written
as-is. This helps implementing patterns like "take a long function and make
it into a struct with a bunch of small functions instead".
> is very difficult to reason about in diffs or any other interface that
isn't an IDE (especially code review)
This is the point where I entirely agree, good code should be easily read
in any context.
Again, may I suggest you take a look into using a style guide to
differentiate visually between local and instance scope?
Ilya
On Sun, Dec 13, 2015 at 10:15 AM, Rob Napier via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
I wanted to reopen this discussion that seems to have trailed off.
Requesting the return of self was my very first ask of Swift if I remember
correctly (Apple Developer Forums). Continued work
in Swift has both strengthened and modified that ask. Here are several of
the examples discussed before:
https://gist.github.com/schwa/94b11dc0a7a331f46b25
Spooky action at a distance when you don't use self · GitHub
Even more shenanigans when self is not required · GitHub
Swift allows you to call instance methods from other instance methods with no scope prefix, indistinguishably from function calls. This leads to the dangerous situation of function calls being shadowed when identically-named instance methods are added to a base class. · GitHub
I get that it seems tedious to type (and read) "self." and I get that
"self." is currently a hint that self might be captured (but doesn't
actually mean that, since you can use self. without capturing, and
sometimes have to, very often in init, so really it's basically meaningless
for that use).
That's why I suggest using .x and .f() to mark implicit self. I realize
that this may conflict with enum usage. If so, then use another marker. For
instance :x or ^x or anything. But implicit self is confusing in a lot of
code, can (and does) lead to shadowing bugs, and is very difficult to
reason about in diffs or any other interface that isn't an IDE (especially
code review).
Thoughts, David? I agree with your basic proposal; I just want to amend
it.
-Rob
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution