Sorry, I didn't mean selectors in the sense of methods, but as a generic 
mechanism for indicating one of any number. My original need was around 
NSNotificationCenter, which uses strings to indicate the notification being 
sent. In an ideal world, these wouldn't be strings under the hood, but whatever 
the mechanism, it should be extensible and typed. 

Sent from my iPhone

> On Aug 6, 2015, at 10:55, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
>> On Aug 6, 2015, at 09:20 , Jens Alfke <j...@mooseyard.com> wrote:
>> 
>> You can't do that, because instances of the subclassed enum won’t be valid 
>> instances of the super-enum.
> 
> I’m not sure that subclassing is what’s being asked for here.
> 
> It seems like it would be useful to be able to define a new enum that has the 
> same cases as an existing enum plus some more cases. These two enums would be 
> separate types, so there’s no confusion. The only special relationship is 
> that (perhaps) it would be legal to assign a variable of the original enum to 
> a variable of the derived enum, since the cases would correspond, but this 
> would be resolved at compile time, not run time.
> 
>> On Aug 6, 2015, at 10:38 , Rick Mann <rm...@latencyzero.com> wrote:
>> 
>> But we need some kind of extensible way of defining a set of valid selectors
> 
> Possibly, but carrying selectors forward into Swift’s future seems like a bad 
> idea. Selectors are an ambiguous way to refer to methods, and that has some 
> advantages as well as some disadvantages.
> 
> Swift has better mechanisms for most things that selectors are used for, such 
> as closures and partial method application, not to mention enums with 
> associated values. The only real “poor fit” I’ve found so far is that you can 
> test selectors for equality, but there’s no == (or ===) operator for 
> closures. As it happened, the micro-redesign I had to do to solve that 
> produced a much better solution overall.
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to