OT: Categories and alloc.
OT: Categories and alloc.
- Subject: OT: Categories and alloc.
- From: Michael Gersten <email@hidden>
- Date: Fri, 28 Jun 2002 13:20:59 -0700
This is sort of off topic, but it's a topic that applies to Java and Objective C developers.
The goal question: How do you allocate from a protocol/interface?
The problem: Objective C and Java both allow protocols/interfaces to specify what you can do with an object. Anything that is written to an interface specification will work with any object that implements that specification, and can work with any class that does so.
But how does it get something of that interface type?
I've posted a lot about the lack of protocol support in Cocoa; that there is no NSCollection (key method: objectEnumerator), NSIndexedCollection (key method: keyEnumerator), etc.
But it has occurred to me that even if you had all that, you'd still have a problem. Allocation.
Very concretely: Lets say you've got a program that uses the HTMLEngine interface. You want to use an HTMLEngine.
Microsoft makes one. Netscape makes one. Opera makes one. Omni makes one. Lynx makes one.
[Lets live in a fantasy for a second. Assume that the HTMLEngine API is a W3 standard, and everyone of those 5 has an engine that implements that API, as well as the output display that uses that engine.]
How does the user tell you which one to use? After all, none of them will display the same way -- one might strive to make the output exactly as the web page designer wants it, another might allow the end user more control over how tags translate into output, a third might give you better control over what graphics and cookies are fetched; they might all have different caching strategies, or ordering to fetch and display the different parts of a web page, etc.
Somewhere, someone has to write
myNewObject = [[ <something> alloc] init]
Right now, <something> has to be either a class, or a function that returns a class.
How do you write something like this so that it's extendable, and works?
For you java experts, how does the class loader system work internally? I know that Java has one default loader that knows how to get classes from the JAR's in the classpath. I know that you can add loaders that know how to get classes from a database store, a web server, or any other location; they can choose to relax security to some extent, or check it tighter, etc.
But how does this all get started?
If I ask java for a class by name, has the initial class loader done a pre-scan of every JAR in the classpath to see if that class is there?
Has it done a prescan to find all the additional class loaders, so that they can be loaded into memory and queried? Or do I have to explicitly load all the class loaders that I know of (which begs the question, how does a new class really get into the system if there isn't even a loader called that can add the class into the system?)
I've come to realize that properties are separate from interfaces.
An NSIndexedCollection is something that has a key based lookup.
They can be arbitrary (copyable) objects, strings (possibly optimized), numbers (not necessarily small, sequential; may be pointers or GUID's), small integers, etc.
That's not 4 separate protocols/interfaces. At best, it's two -- is the key an object or an int. Between NSNumber or java number objects, that can become one. An array with PropSparse (indexed by GUID's) will not be the same as PropTailChanges (typical NSArray, with an array allocated), or PropRandomInserts (probably a linked list implementation instead). PropNumericKey (NSArray) is different from PropStringKey, or the default of PropCopyableKey (NSDictionary).
A collection (NSCountedSet) with PropGuaranteedUnique (an optimized version of NSSet that doesn't have to check for duplicates) is not the same as PropIgnoreDuplicates (NSSet). The API's can be identical.
If the goal is to write a package of functions so that the main function can take a protocol/interface name, a bunch of wanted properties, and determine which "actual" class (or class cluster) best implements those properties, then what API does this package need? How can it adequately allow new classes to be added to support this?
Keep in mind that adding new classes/packages can be done by the end user, with no access/ability to change the source or main executable. That means it ultimately has to be able to scan a CLASSPATH, or a PACKAGEPATH, or a FRAMEWORKS_PATH, or something like that.
I'm looking for ideas. I haven't even begun looking at the security issues (what if a package on the system doesn't really do what it claims, or does do what it claims, but also copies the data for someone else [no big brother concerns here, nope, nada]).
Michael
--
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.