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: Mon, 01 Jul 2002 22:32:59 -0700
>
> The goal is to be able to allocate a class that isn't known at compile
>
> time, based on the output of a function.
>
>
A class is actually a struct. You could malloc one and use
>
objc_addClass() to add it to the runtime. There may be an easier way to
>
do this.
Ok, misunderstanding. I don't want to create a new class structure.
I want to create an instance of a class.
But when I'm writing my code, I don't know what class it will be. I
know the API that I want to use. I know the properties that I want to
use.
And, I
>
> ... want to be able to load new classes that weren't known when the
>
> program was written.
>
Restricting the loading to just one class isn't going to add security.
>
That class can still do anything to any class it wants to. Also, I
>
doubt this would be possible. I don't think you can know what's in a
>
binary without loading it. Could you explain more about why you want to
>
do this?
I've given up on any idea of security, so that's no longer a concern.
As to why, as I just told someone else privately,
>
> Actually, I'm trying to figure out how to do something along the lines
>
> of
>
> myCollectionObject = [[ classChooser(NSCollection, property1,
>
> property2, null) alloc] init]
>
> where classChooser would be a function that returned a class, given a
>
> protocol and some desired properties. ClassChooser would figure out
>
> which class that implements the protocol has the desired properties,
>
> and return that.
>
>
>
Umm, I'm not sure what's so difficult about that?
>
Simply write a C function that returns a class object...
Ok, lets examine the idea of class clusters.
You want to allocate something that obeys the NSString protocol.
Do you get an NSInlineCStringWithGap? How about NSConcreteString?
Those are the two that I know of. I'm sure that there's another one
for dealing with a sting backed by a UTF-8 disk file, or another for a
UTF-16/unicode file. There's probably another for UCS-4/"true unicode"
files. (Unicode is NOT a 16 bit character standard. The 16 bit is
simply the most common encoding. There are more than 65536 unicode
character elements.)
What you have with NSString, and it's descendants, is basically a
system where you specify, by an init call, some _implied_ desired
properties. And, there is a fixed, _non-extendable_ map between those
properties and a destination class.
Ditto with NSDictionary, etc.
Yes, I can make a new NSString, and create it explicitly. But nothing
else on the system will know about it or use it.
Now do you start to understand?
The idea is to say that all such allocation, instead of using hard
coded class names, goes through some extendable "Here's what I want to
do". Maybe I want a really large array that will NOT be accessed
locally -- accessing elements 5, 6, 7, implies that I'll not need 5,
6, or 7 again, but I'll need 8, 9, and 10 next. That's the opposite of
traditional LRU memory retention/paging algorithms. Maybe it's
completely random, and any attempt to pre-fetch will only take memory
away from something else that really needs to keep that memory.
Maybe I know that this dictionary, althoug being initted with the
contents of a file, is such a large file that the normal NSDictionary
class is totally slow and inappropriate. But if I know that there's an
index for that file, and a custom NSDictionary class can use that
index, then a new class will work better -- even if I'm not the one
calling the init call (if it's buried in a library, or in someone
else's code).
Now, consider that the list of properties is not fixed and known ahead
of time. A year ago, I wouldn't have thought of classes being loaded
out of a database, but now I know that for 24/7/365 java server farms
that's a very useful feature (along with "Just stick the new version
of the class in there, and when all the old instances of the class are
gone, the old code will be garbage collected as well".)
Nor would I have thought of a DB-based very large NSDictionary. Hey,
databases can hold terrabytes now, over multiple disks -- an
NSDictionary might be larger than total RAM, or larger than configured
MAX_HEAP.
--
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.