I love that idea to have namespaces as first class objects in ObjC, but I'd go even further.
Why not having nested @interfaces directly, and have that @namespace become an actual class.
So we just add the @using to avoid the need to put the class at every levels and we use message syntax directly to get a class outside of the current "namespace".
I'd say such nested class would behave like a class method, so it would only prevent you from naming a class-method the same way as a nested class. Also classes would still usually start with a capital case, so it doesn't overlap with normal methods anyway (I don't suggest to enforce that convention).
For the selector namespaces, what I think the most problematic part is the methods in categories and especially private categories, I think that if we want to have such namespaces it's to avoid categories, for example on NSString, to interfere with future additions to the main categories by say Apple, in this sense maybe we could have namespaces selectors on categories only...
And also, I still think it'd be great to have @private/@protected/@package methods, for @private methods, since they are not supposed to be called outside a class, it doesn't really matter to have them resolved at compile (this is a place where dynamism would be a bigger problem than anything else). For the other scopes (and even from @private if we want to keep it dynamic), we can have the _cmd parameter to take the class object of the class that sends the message, in the same way that [super message] works, so the runtime can check if the caller can do the call.
Remy "Psy" Demarest
Le 10 avr. 2012 à 14:55, John Buckley a écrit :
> 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...
>
> 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.
>
> 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];
>
> Regards,
>
> John
>
> ------------------------
> Dr. John Buckley
>
> Olive Toast Software Ltd
> www.olivetoast.com
> ------------------------
>
>
>
> On 10 April 2012 17:45, Michael Ash <email@hidden> wrote:
>> On Apr 10, 2012, at 12:01 PM, Jean-Daniel Dupas wrote:
>>
>>>> Plenty of other languages do namespaces without much complexity at all, let alone the mind-numbing kind.
>>>
>>> They don't have to deal with dynamic message dispatching.
>>> Having to specify the namespace to call a method is not something usual AFAIK.
>>
>> 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.
>>
>> If having to specify the namespace to call a method is unusual, then perhaps that's not the correct approach. But it seems clear enough that Objective-C can have namespaces without adding a huge amount of complexity, since other languages *with similar capabilities* do it just fine. Instead of rejecting the idea out of hand, let's look at how these other languages do it and see what good ideas they have that we can borrow.
>>
>> Mike
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
_______________________________________________
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
