OOP and Foundation 4: Class Protocols
OOP and Foundation 4: Class Protocols
- Subject: OOP and Foundation 4: Class Protocols
- From: Michael Gersten <email@hidden>
- Date: Mon, 10 Jun 2002 13:41:10 -0700
Point 4:
I had originally said that all I care about of an argument is the messages that I can send it, and its public data members. (Part of the general protocol, but not part of the ObjC language protocol concept.)
Anytime I define a class, there should be a protocol for that class defined as well.
I should never say "I take this class as an argument", I should say "I take something that follows this protocol". Even for output -- the output might be an NSProxy or NSProtocolChecker to an object of the specified class.
The details:
>
From a language design point, the only reason that I should declare a specific class type of an argument is if I'm working with a class I know the details of -- either an explicit friend (a C++ concept that thankfully did not make it into ObjC), or my own class (and I violate the 'access by accessors' rule and peek directly -- a nono.).
If neither of those is true, then I only care about the protocol that it obeys.
It's not hard to imagine the compiler generating a protocol for each class, or even a pair of protocols -- one for the public methods, one for all the methods.
These class protocols could be used to declare arguments. Almost always, I'd use the public methods protocol for declaring my arguments.
You could even imagine a subclass of NSProtocolChecker that takes a class protocol name, and at run time, looks it up (once), to find the latest-and-greatest version of the class protocol, or public class protocol, and uses that instead of the "this is what was public 5 years ago" version. In other words, I'd give it the class protocol name (my old code), and it looks up the protocol (current library's code).
Now, categories and their effect on this. I can think of four options:
1. Anything in a category doesn't go into the class protocol.
A class's protocol is contained in a bunch of class-category protocols.
Requires that the runtime can take two or more protocols, and merge them.
Requires that the list of categories is known to the end user.
Not that good of an idea.
2. All categories for a class are merged into a protocol.
Requires that the linker deal with protocols just like it deals with object files.
Requires a syntax change (@private) for private methods.
- OR - Require that the programmer honors the _ = private convention.
3. The runtime does protocol merging
The runtime already has all the categories and methods
The runtime can easily ignore any category that begins with an underscore
The runtime can easily ignore any method that begins with an underscore
In fact, the runtime can build these protocols by walking the method lists.
No compiler or linker changes at all
Provides private methods in a manner compatible with most programmers
Needs some special casing for storedValueForKey: and takeStoredValue:forKey:
(a subclass of NSProtocolChecker)
Cannot provide compile-time checking.
(the biggie.)
4. Combination of 2 and 3:
The compiler is modified to know that a class category contains all the methods it has seen declared for a class, including the parent classes, excluding _ methods.
Because different compiled units might see different sets of categories, it is up to the runtime to actually build these protocol objects, for the method calls that need them.
This gives you compile time checking, with the least changes to the language/compiler.
This gives you all the runtime support you need, with minor changes (a function to walk the method lists, something to catch runtime cache invalidations and rebuild these protocols [bundle loading], and an initial call to this setup either just before startup calls main, or as the first line of main.).
And, for objective C, all of this requires that none of the classes have accessable Ivars -- everything through valueForKey: (or equivalent -- storedValueForKey:, etc.) or method calls.
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.