Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider behavior of un-namespaced selectors #4

Open
kylesluder opened this issue Feb 9, 2014 · 1 comment
Open

Reconsider behavior of un-namespaced selectors #4

kylesluder opened this issue Feb 9, 2014 · 1 comment
Labels

Comments

@kylesluder
Copy link
Owner

Currently, sending an un-namespaced message to an object searches the object's methods for one with a "compatible" selector.

I'm questioning whether un-namespaced selectors are a good idea at all, or if they should just belong to the default namespace.

There are three motivations for un-namespaced selectors:

  • Some existing code relies on calling private methods in framework code; if these methods move to a private namespace, then that code will break.
  • Some framework classes rely on unwritten convention. For example, NSScrollView sends -headerView to its document view to figure out what view to stuff above the scrollable area.
  • Key-Value Coding constructs selectors from keypath strings, and these strings do not include namespaces.

It's possible to solve these problems, to greater or lesser degrees, without involving un-namespaced selectors:

  • Existing Apple frameworks should not adopt namespaces. Selectors emitted by existing client code would be treated as living in the default namespace. (Apple frameworks could adopt namespaces for new private code.)
  • Conventions like -headerView should be formalized. For example, there should be a declaration of a -headerView method in a category on NSView. This isn't an airtight solution; depending on where this category declaration lives, a subclass of NSView might not see it, and accidentally declare a method -headerView in its own namespace rather than the default namespace, undetectable to the compiler. The declaration of -headerView would have to live alongside NSView's @interface to ensure that the compiler would resolve the method definition to the declaration in the appropriate namespace.
  • Barring more substantial changes, KVC could adopt the resolution mechanism currently described for matching un-namespaced selectors to their namespaced definitions. This doesn't create any new problems; it's already an undetectable error condition if a subclass adds a property that conflicts with a private KVC property declared by its superclass.
@kylesluder
Copy link
Owner Author

One idea I started working on in 09aecd1: make it impossible for namespace-aware code to emit a non-namespaced selector, but still support the dynamic lookup for interoperability with old code.

(It would probably still need to be possible to create a non-namespaced selector using runtime functions. That means NULL could not be used to refer to the global namespace in some hypothetical sel_getUid2(ns, kw). Perhaps the empty string?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant