[swift-evolution] Pitch: Import Objective-C Constants as Enums

[Jacob Bandes-Storch]

If the method param is annotated, not only does the user get a hint for
where to look in the docs, but you can omit the type name qualification,
saying quantityForTypeIdentifier(.BodyMass).

Sounds great to me.

Jacob

On Mon, Jan 18, 2016 at 10:20 AM, Jeff Kelley via swift-evolution <
swift-evolution at swift.org> wrote:

> On Jan 18, 2016, at 12:41 PM, Philippe Hausler <phausler at apple.com> wrote:
>
> One note to those constants; there are a number of them (NSError domains
> in particular) that are intended to be a complement to the application
> space defines; such that your app could define a “MyGreatAppErrorDomain”
> and a “MyGreatFrameworkErrorDomain” in addition to the NSCocoaErrorDomain.
> So this isn’t exactly an enum but more so a non closed set of values. Enums
> are usually closed sets so that they can be switched upon exhaustively.
> Others would definitely improve the state of affairs for both objc and
> swift in that technically you could get a warning/error in objc if the type
> was not correct and there would be the swift ramifications you mentioned as
> well.
>
>
> Great point, and for that reason I switched away from NSError domains in
> my proposal. It’s a much more clear win to use this for something like
> HealthKit constants where values outside of the constants may not be used.
> For NSError domains, leaving the type as NSString is probably best to
> indicate that custom strings are supported.
>
> On the other hand it might be useful for the (desperately in need of some
> updating) NSLocale method
>
> @interface NSLocale : NSObject <NSCopying, NSSecureCoding>
> ...
> - (nullable id)objectForKey:(NSLocaleKey)key; // we could limit the keys
> accepted here to just the appropriate values in the “enum"
> ...
> @end
>
>
> From a brief survey of the APIs this would be useful for they mostly seem
> to be “dictionary based programming” cases which expose poorly in swift
> because they don’t have type safe return values. Adding more swift-friendly
> interfaces to those APIs is not off the table; because it is not just the
> keys that are the issue here but the return values too (see NSLocale’s
> example). Not to say we couldn’t do both, but would it be the case that if
> the un-typed return values that access by keys are replaced with better,
> more safe interfaces, this still be needed?
>
>
> The “dictionary based programming” examples could definitely use a bit of
> an API refresh, as you’ve noticed with the return types. This proposal’s
> real aim is APIs that use strings to mean one of a finite set of values.
> Take HealthKit:
>
> + (nullable HKQuantityType *)quantityTypeForIdentifier:(NSString
> *)identifier;
>
>
> The return value here is typesafe, but the identifier is a string.
> HKTypeIdentifiers.h defines these identifiers. Here’s one set:
>
> HK_EXTERN NSString * const HKQuantityTypeIdentifierBodyMassIndex;
> HK_EXTERN NSString * const HKQuantityTypeIdentifierBodyFatPercentage;
> HK_EXTERN NSString * const HKQuantityTypeIdentifierHeight;
> HK_EXTERN NSString * const  HKQuantityTypeIdentifierBodyMass;
> HK_EXTERN NSString * const HKQuantityTypeIdentifierLeanBodyMass;
>
>
> Since the user isn’t permitted to use their own identifiers here, this is
> an ideal case for replacement. It also gives the user a better hint as to
> where to find these constants. Rewriting the Objective-C method along these
> lines:
>
> + (nullable HKQuantityType
> *)quantityTypeForIdentifier:(HKQuantityTypeIdentifier)identifier;
>
>
> Would give the user a hint in the name of the type for where to look in
> the documentation for these identifiers.
>
> I think frameworks like HealthKit with constant string identifiers would
> benefit greatly from this change, as would other frameworks like CoreText
> with opaque keys and values used to construct dictionaries.
>
>
> Jeff Kelley
>
> SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> |
> jeffkelley.org
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/5e8bbd70/attachment.html>