Re: Swift enums and NSNotificationCenter
Re: Swift enums and NSNotificationCenter
- Subject: Re: Swift enums and NSNotificationCenter
- From: Uli Kusterer <email@hidden>
- Date: Thu, 06 Aug 2015 13:03:33 +0200
On 06 Aug 2015, at 02:19, Rick Mann <email@hidden> wrote:
> On Aug 5, 2015, at 17:14 , Jens Alfke <email@hidden> wrote:
>> It’s part of the language design that only classes support inheritance, not structs or enums.
>>
>> Basically, subclassing pass-by-value types is problematic. For example, what happens when you assign a SubclassStruct value to a variable of type BaseStruct, or pass it to a function parameter of type BaseStruct? Do the extra instance variables get chopped off when it’s copied? What happens if you call a BaseStruct method that was overridden in SubclassStruct?
>>
>> C++ lets you do this, but it can lead to really nasty problems, so style guides like Effective C++ recommend avoiding it.
>
> But for extending the cases in an enum, it seems pretty nice.
It seems pretty nice until you need to optimize it. If e.g. the original enum had <= 256 different values, it might have been implemented as a uint8_t behind the scenes. Now someone subclasses it and adds the 257th Where do you store that value now? Or even if it is a fixed size and still large enough to hold the value, what if the base enum is in the system and an application adds its own types to it? If the system ever adds another value, you might have two indistinguishable values for two different meanings.
There are ways around this: You could have sub-enums declare their cases as globals which get initialized at load-time by adding to the last value of the base-enum, but then you lose any guarantees about the rawValue of an enum ... it just becomes really messy really quick, and still has a tendency to break when the base-enum fills up its storage. For cases like that you might as well use a string property, which will be less likely to collide.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden