On Apr 5, 2012, at 3:22 AM, Sam Deane <email@hidden> wrote:
> In my initial reading of the proposal, the two constructs that jumped out at me were:
>
> [<receiver> @namespace(<ns>) arg1:... arg2:...];
This escape hatch is hopefully exceedingly rare. It mainly exists because ARC is weaning people off -performSelector:.
>
> and
>
> [@class(ns.SomeClass) description];
I think @class() makes a great feature on its own. It exposes a feature the compiler already has (at least on the modern runtime): the classref symbols which are patched by the loader.
>
>
>
> These don't feel idiomatic to me.
>
> I confess that the feeling is intuitive, but in an attempt to rationalise it the one thing I could come up was that inside code blocks, @ directives are generally used to define things that are effectively literals (eg @"", @selector, @encode, plus the new literal support).
@class is a literal in this case. It becomes a dereference of an OBJC_CLASS_$_ symbol.
>
> The @namespace and @class directives here seem to be annotations to disambiguate type, and as such are a bit different.
>
> I'm not sure if "it feels a bit wrong" is a valid criticism, but I offer it up anyway.
>
> My preferred solution would be to find an unambiguous syntax to indicate namespace scope that you could use instead of a dot. You could then use it in @selector too.
>
> The most obvious solution that springs to mind is "::":
>
> [myObject myNamespace::arg1:... arg2:...];
> [myNamespace::SomeClass description];
> @selector(myNamespace::arg1:arg2:)
> @selector(::arg1:arg2:) // :: indicates nil namespace?
>
>
> It's so obvious that I assume you thought of it, so no doubt there's a reason to avoid it :)
I deliberately avoided the double colon notation for the reason Mike Ash pointed out, as well as to avoid implying that ObjC namespaces were in any way related to C++ namespaces.
It would be especially confusing if ::selector referred to a selector with no namespace (remember, there is no such thing as "the nil namespace"), while ::CPlusPlusThing referred to something in the anonymous namespace (analogous to ObjC's default namespace).
>
> I feel (again, intuitively) that you should be aiming to create the minimum of new @ directives (but I'm not sure that overloading existing ones with new meanings or variants is any better).
I think everyone would agree that @namespace...@end blocks are a necessary feature of a traditional namespace implementation. Overloading that new keyword to produce a context-free syntax for what is hopefully a very rare operation seemed like the least-bad solution. And as I said above, I like @class() enough on its own. :)
--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
