Changing postfix "self" to something clearer like "type"


(Ethan Diamond) #1

+1 that I find .self confusing. This would only apply for classes,
structs, protocols and enums, right? What about this:

ClassType.class

StructType.struct

ProtocolType.protocol

EnumType.enum

None of those are likely to be used as actual properties anywhere.
They would be pretty safe keywords to reserve.

* On Dec 15, 2015, at 1:24 PM, Jordan Rose <jordan_rose at apple.com <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:

*> >* ".self" was chosen for a few reasons:
*> >* - The obvious choice was ".class", given precedent in
Objective-C and Java, but not all types are classes.
*>* - 'type' is a very common property name, so we have tried very
hard to avoid taking it as a general keyword.
*>* - 'type' also always implies going up a level. "obj.dynamicType"
gives you back the type of 'obj', so wouldn't "SomeClass.type" give
you back the metaclass
<http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html
<http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html>>?
(Alternately, "SomeType.staticType' not being the same as
'SomeType.dynamicType" seems weird.)
*>* - 'self' is already a keyword.
*>* - ".self" actually works in Objective-C as well.
*>* - ".self" currently also applies to instances, doing exactly what
you think it does. This is nearly useless. In theory you could use it
to unwrap one level of optionality ("doubleOpt?.self") but that
doesn't actually work today.
*> >* I read "SomeType.self" as "SomeType itself, rather than an
instance of it (or associated type)".
*> >* (And before someone brings it up, we chose not to just allow
"SomeType" on its own because "let x = SomeType" is a likely typo for
"let x: SomeType".)
*> >* I think coming up with a clearer name is possible here, but
there's plenty to consider. Still, certainly a reasonable thing to
bring up.
*> >* Best,
*>* Jordan
*> >>* On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution
<swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<mailto:swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
*>> >>* Doh! staticType is the obvious choice!
*>> >>* I agree that adding more keywords can be bad, but in this case
I think the clarity outweighs any downside:
*>> >>* SomeType.staticType
*>>* SomeType.self
*>> >>* To me (and I'm sure many others) one is vastly more obvious
and easier to understand.
*>> >>* I still don't really understand what SomeType.self is trying
to convey upon first glance
*>> >>* Brandon
*>> >>* Sent from my iPad
*>> >>* On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko

···

at gmail.com <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:dennis.s.lysenko at gmail.com <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
*>> >>>* +1. Side effects can be eliminated through code migration if
a suitable property name is chosen. Perhaps `staticType` to continue
in the vein of `dynamicType`?
*>>> >>>* Main detractor is that creating more keywords isn't
necessarily a good thing.
*>>> >>>* On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via
swift-evolution <swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<mailto:swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
*>>>* One area of swift that is really not clear to me is when you
want to use the type of a class, struct, enum, etc as a value.
*>>> >>>* Metatyping is explained here:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022>
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022>>
*>>> >>>* Example:
*>>>* let metatype: SomeClass.Type = SomeClass.self
*>>> >>>* Is there a reason why this isn't SomeClass.type? Everywhere
in the document this is explained as returning the type yet it's using
a postfix self to access the type.
*>>> >>>* I propose changing the postfix self to something more
obvious like "type"
*>>> >>>* Going back to the example:
*>>>* let metatype: SomeClass.Type = SomeClass.type
*>>> >>>* Several reasons why I think this is better:
*>>>* 1. Postfix self is not obvious as an option as you never see a
postfix self anywhere else
*>>>* 2. "self" does not clearly explain that the type is being returned
*>>>* 3. ObjC programmers are familiar with accessing the class type
by sending the "class" method to the class type. In this case it needs
to work on structs and enums, so a "type" method would make more
sense.
*>>>* 4. Instances have a dynamicType method. For consistency,
classes, structs, etc., should have a type method
*>>> >>>* Any other suggestions would be welcome.
*>>> >>>* Brandon
*>>> >>>* Sent from my iPad
*>>> >>>* _______________________________________________
*>>>* swift-evolution mailing list
*>>>* swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<mailto:swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>>
*>>>* https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>>
*>>* _______________________________________________
*>>* swift-evolution mailing list
*>>* swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<mailto:swift-evolution at swift.org
<https://lists.swift.org/mailman/listinfo/swift-evolution>>
*>>* https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
<https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>>*


(Jordan Rose) #2

What do you do for tuples, function types, generic parameters, and protocol compositions?

I'm being a bit facetious, but I do want to note that we went through a fair amount of bikeshedding ourselves; if there's an "obvious" answer, there's probably a reason we didn't pick it.

Best,
Jordan

···

On Jan 7, 2016, at 12:22, Ethan Diamond via swift-evolution <swift-evolution@swift.org> wrote:

+1 that I find .self confusing. This would only apply for classes, structs, protocols and enums, right? What about this:
ClassType.class
StructType.struct
ProtocolType.protocol
EnumType.enum
None of those are likely to be used as actual properties anywhere. They would be pretty safe keywords to reserve.
> On Dec 15, 2015, at 1:24 PM, Jordan Rose <jordan_rose at apple.com <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
>
> ".self" was chosen for a few reasons:
>
> - The obvious choice was ".class", given precedent in Objective-C and Java, but not all types are classes.
> - 'type' is a very common property name, so we have tried very hard to avoid taking it as a general keyword.
> - 'type' also always implies going up a level. "obj.dynamicType" gives you back the type of 'obj', so wouldn't "SomeClass.type" give you back the metaclass <http://sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html>? (Alternately, "SomeType.staticType' not being the same as 'SomeType.dynamicType" seems weird.)
> - 'self' is already a keyword.
> - ".self" actually works in Objective-C as well.
> - ".self" currently also applies to instances, doing exactly what you think it does. This is nearly useless. In theory you could use it to unwrap one level of optionality ("doubleOpt?.self") but that doesn't actually work today.
>
> I read "SomeType.self" as "SomeType itself, rather than an instance of it (or associated type)".
>
> (And before someone brings it up, we chose not to just allow "SomeType" on its own because "let x = SomeType" is a likely typo for "let x: SomeType".)
>
> I think coming up with a clearer name is possible here, but there's plenty to consider. Still, certainly a reasonable thing to bring up.
>
> Best,
> Jordan
>
>> On Dec 15, 2015, at 8:42 , Brandon Knope via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
>>
>> Doh! staticType is the obvious choice!
>>
>> I agree that adding more keywords can be bad, but in this case I think the clarity outweighs any downside:
>>
>> SomeType.staticType
>> SomeType.self
>>
>> To me (and I'm sure many others) one is vastly more obvious and easier to understand.
>>
>> I still don't really understand what SomeType.self is trying to convey upon first glance
>>
>> Brandon
>>
>> Sent from my iPad
>>
>> On Dec 15, 2015, at 11:34 AM, Dennis Lysenko <dennis.s.lysenko at gmail.com <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:dennis.s.lysenko at gmail.com <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
>>
>>> +1. Side effects can be eliminated through code migration if a suitable property name is chosen. Perhaps `staticType` to continue in the vein of `dynamicType`?
>>>
>>> Main detractor is that creating more keywords isn't necessarily a good thing.
>>>
>>> On Tue, Dec 15, 2015 at 11:19 AM Brandon Knope via swift-evolution <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>>> wrote:
>>> One area of swift that is really not clear to me is when you want to use the type of a class, struct, enum, etc as a value.
>>>
>>> Metatyping is explained here: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022 <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-XID_1022>
>>>
>>> Example:
>>> let metatype: SomeClass.Type = SomeClass.self
>>>
>>> Is there a reason why this isn't SomeClass.type? Everywhere in the document this is explained as returning the type yet it's using a postfix self to access the type.
>>>
>>> I propose changing the postfix self to something more obvious like "type"
>>>
>>> Going back to the example:
>>> let metatype: SomeClass.Type = SomeClass.type
>>>
>>> Several reasons why I think this is better:
>>> 1. Postfix self is not obvious as an option as you never see a postfix self anywhere else
>>> 2. "self" does not clearly explain that the type is being returned
>>> 3. ObjC programmers are familiar with accessing the class type by sending the "class" method to the class type. In this case it needs to work on structs and enums, so a "type" method would make more sense.
>>> 4. Instances have a dynamicType method. For consistency, classes, structs, etc., should have a type method
>>>
>>> Any other suggestions would be welcome.
>>>
>>> Brandon
>>>
>>> Sent from my iPad
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution> <mailto:swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution