[swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types
jeremy.j.pereira at googlemail.com
Thu Apr 21 07:38:14 CDT 2016
> On 20 Apr 2016, at 18:16, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> * What is your evaluation of the proposal?
Addressing the issues cited in the proposal:
> • dynamicType remains an exception to Swift's lowercased keywords rule. This change eliminates a special case that's out of step with Swift's new standards.
Except for the fact that `dynamicType` cannot be used with implicit self, it has always felt more like a property to me than a keyword and the capitalisation is therefore not out of place. The camel case does not jar for me in the same way that writing `someInstance.Self` would.
NB the keyword `Self` would also violate the all-lowercase keyword rule.
> • Self is shorter and clearer in its intent. It mirrors self, which refers to the current instance.
It is undeniably shorter, but it is not clearer in intent. `self.dynamicType` clearly and explicitly tells us we are referring to the runtime type of the instance. `Self` does not. Furthermore, it overloads the word with two subtly different meanings depending on context.
> • It provides an easier way to access static members. As type names grow large, readability suffers. MyExtremelyLargeTypeName.staticMember is unwieldy to type and read.
I reject the assertion that readability suffers with large type names. `NSApplicationDelegate` is much more readable than `NSAppDlgt` for example.
Furthermore, this proposal does not address the length of `MyExtremelyLargeTypeName.someMember()` since that might not be the same method as `Self.someMember()` If you explicitly want the `someMember()` defined by `MyExtremelyLargeTypeName` you still have to spell it out in case it is a class function and the dynamic type is a subclass.
> • Code using hardwired type names is less portable than code that automatically knows its type.
And how does `self.dynamicType` fail here?
> • Renaming a type means updating any TypeName references in code.
This is the same point as the previous one.
> • Using self.dynamicType fights against Swift's goals of concision and clarity in that it is both noisy and esoteric.
I disagree. `self.dynamicType` is a clear and concise description of the object it represents.
Another observation: the proposal omits the “Impact own Existing Code” section. I think this would be a breaking change for a lot of existing code.
Also, I’m disappointed that no alternatives seem to have been documented.
> * Is the problem being addressed significant enough to warrant a change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
No, unless the direction of Swift is to go for maximum terseness at the expense of clarity.
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
In Objective-C you can write [self class] to get the runtime class of an object. I think that is a better choice of name. In Swift the analogue would probably be `self.type`. Was this considered?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve been following the thread.
More information about the swift-evolution