> On 20 Apr 2016, at 18:16, Chris Lattner via swift-evolution > <[email protected]> wrote: > > > * What is your evaluation of the proposal?
-1 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? No. > * 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
