Re: RFC: Allocating via a protocol/interface
Re: RFC: Allocating via a protocol/interface
- Subject: Re: RFC: Allocating via a protocol/interface
- From: Michael Gersten <email@hidden>
- Date: Tue, 02 Jul 2002 13:50:58 -0700
Exactly.
Edwin Zacharias wrote:
>
OK, I see what you want to do now. Since you're not worried about
>
security you could put all the info about the bundle in its Info.plist,
>
although you're limited in terms of data structures then.
>
...
>
I think I understand this. You want your function to operate like a
>
class cluster for every class. You want it to pick the best class for
>
your requirements and return that. Often times this is not about
>
interface, it's about implementation.
That is exactly it.
The idea of using protocols at the level of NSCollection,
NSOrderedCollection, etc., or HTMLEngine, etc., is to say that I don't
care how it works, only what I can do with it. I'm concerned now with
"which one do I use?".
>
The only way I can think to do this is to create a system where classes
>
can define their abilities using common keywords and then rank them.
>
For example:
>
>
MyNewArray = {
>
abilities = {
>
"linear search" = 9;
>
"random search" = 4;
>
"append object" = 8;
>
"insert object" = 1;
>
"sparse objects" = 9;
>
"very large" = 6;
>
"very small" = 1;
>
};
>
protocols = (
>
"NSObject",
>
"NSArray",
>
"NSCoding"
>
);
>
};
>
>
Of course, a valid ranking system would be pretty difficult.
Not just difficult, but extendable. How big is very large -- 30% of
available memory? 300% of available memory?
I like this as a start. This eliminates having to load a description
class just to return information about the real class. This could be
extended if a class needs something else to load it (like a custom
java class loader -- a web server, a database, etc), or if I'm
describing a legacy class that doesn't have such a description. Or if
the list is extended in the future, such as bundle dependencies or
known conflicts.
What do I see as problems? Protocols being listed seperately from the
code. I can't see any way around that without loading all the code
bundles up front, which I'm trying to avoid because of potential
conflicts (as well as load time). Typos -- all those attribute
strings, all that possibility of unchecked spelling errors. Gotta find
a way to auto generate this list from the source. Not the first
version (:-).
Hmm... So now I'm at:
This basic idea (Plist descriptions and a parsing framework)
Plus the idea of "Here's more information to add about class foo",
along with "Here's an override to remove from class foo" (legacy
support, patching)
All these plist descriptions with a ranking/ordering (so that vendor
supplied information, patched information from added
categories/frameworks, global app preferences, global user
preferences, and app/user preferences can all live together)
[ User preferences will probably live in the defaults database
instead of an empty bundle ]
Optional: a code-based API to register a plist dictionary. Usable by
a proxy.
as the pieces to make this all work.
>
- Edwin
--
I am a Mac OS X-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.