+1 to this. I commonly reference self alone very close to
self.dynamicType when I use the dynamicType keyword, and I dislike the
repetitiveness it brings. If a standalone dynamicType is already
disallowed by the compiler, I don't see a technical reason this cannot
happen, personally. If this can happen, then self should probably still
be required to qualify dynamicType in closure contexts (for
consistency), for example:
class Foo {
let value = 123
func bar() {
dispatch_async(queue, {
print(self.dynamicType.value) // self needed here in this closure
})
}
}
On 4/10/2016 5:15 AM, Mohamed Ebrahim Afifi via swift-evolution wrote:
> Hi,
>
> When access the `dynamicType` of a class inside one of its instance
> methods. We should be using `self.dynamicType`. I purpose that the
> dynamicType operator can be accessed without the need for the `self`.
> So code like the following
>
> class Foo {
> static let SomeStaticConstantValue = 5
> static func someStaticMethod() {
> }
>
> func bar() {
> self.dynamicType.someStaticMethod()
> print(self.dynamicType.SomeStaticConstantValue)
> }
> }
>
> can be translated to
>
> class Foo {
> static let SomeStaticConstantValue = 5
> static func someStaticMethod() {
> }
>
> func bar() {
> dynamicType.someStaticMethod()
> print(dynamicType.SomeStaticConstantValue)
> }
> }
>
>
> Best Regards,
> Mohamed Afifi
>
>
> _______________________________________________
> 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
