On Apr 10, 2012, at 11:55 AM, John Buckley wrote:
> On 10 April 2012 17:45, Michael Ash <email@hidden> wrote:
>>
>> There are other, good languages that have both namespaces and dynamic dispatch. Ruby is one example that comes to mind off the top of my head.
>
> To my mind there are two issues we're trying to deal with:
>
> 1. namespaces for classes, functions, variables and other standard types.
> 2. namespaces for selectors.
>
> I can see how 1. would be a useful addition to the language. I'm very
> unsure that the trade-offs involved in 2. (increased complexity, at
> least in the current proposal) are worth it. Dynamic dispatch as it is
> currently implemented is the very heart and soul of Objective-C (and
> Smalltalk) and I'm against any proposal which moves method resolution
> to compile time (let's ignore properties for now). If it walks like a
> duck…
I am not proposing we resolve methods at compile time. I'm proposing we resolve selector namespaces at compile time. Just like how the compiler resolves method signatures at runtime so it can generate the appropriate objc_msgSend variant. The actual dispatch will still be dynamic.
>
> At the very least I'd want to restrict selector resolution to a
> runtime method (e.g. objc_namespaceResolveSelector(...)) rather than
> the currently proposed @selector changes.
This would be a good feature to have, and would probably be necessary if you wanted to implement your own resolution of non-namespaced selectors (for dealing with legacy code, for example). In any event, the runtime would certainly need this functionality for resolving non-namespaced selectors within objc_msgSend, so it makes sense to expose it as API.
>
> I'm also wondering why no one has suggested the obvious (to me) idea
> of treating namespaces as first-class objects as we do for Class.
> Objective-C is all about objects after all. So for example to obtain a
> Class from a namespace just send a message to the namespace as we now
> do to allocate a class, e.g.
>
> Class aClass = [default NSObject]
> and
> id foo = [[[Namespace Foo] alloc] init];
>
> This seems so much more natural to me than @class() or the dot syntax
> and requires no new syntax (other than @namespace and @using) or
> further operator overloading. Namespaces could even support properties
> (c.f. python) and there would be no ambiguity using the dot operator
> for property access (or in structs).
>
> For similar reasons I'd also be in favour of spaces when writing declarations:
>
> // .h
> @namespace com.OliveToast
>
> @interface CoolView : UIKit UIView <UIActionSheetDelegate>
> ...
> @end
> @end
>
> // .m
> // Variable declaration
> com.OliveToast CoolView *coolView = [[[com.OliveToast CoolView] alloc] init];
This is interesting, but it doesn't address how you specify that you want to send an object the -doSomething message from the OliveToast namespace, not the one that Apple implemented in a private class extension in a point release of the operating system.
It also adds new wrinkles to the already complicated parsing rules for C declarations. I was trying to avoid that in part because I'm not a seasoned parser writer, so I didn't want to accidentally introduce ambiguities into the grammar. Keeping namespaces attached to the existing type information minimized that possibility.
--Kyle Sluder
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
