Re: Instance Variable access
Re: Instance Variable access
- Subject: Re: Instance Variable access
- From: Allan Odgaard <email@hidden>
- Date: Mon, 10 May 2004 13:34:38 +0200
On 10. May 2004, at 4:39, Andy Lee wrote:
Like the current use of hashing ;)
Sort of, but with the reminder that hash values per se are not used
for looking up a class's implementation of a method. The
method-lookup table uses a unique lookup key -- a SEL -- and not a
hash value, which is not guaranteed to be unique for all method names.
I was thinking of "(uint32_t)selector % ARRAY_SIZE" as hash-value -- if
you do not "modulo" it, then the table needs to be as big as the
highest SEL-value, and since these are unique, that could result in
some rather large arrays, pr. class.
By run-time do you mean the conversion is done at class-load time or
message-send time?
I only meant when the program was running as opposed to when it is
compiled. I.e. I cannot compile a program for your computer and
hardcode the selector values (because these are not known until
run-time).
The actual registration of a name will happen at many different times,
e.g. you may have an action message set to "performAction:" in IB,
which will most likely be registered in initWithCoder: (when loading
the nib), you may use @selector(dummy) somewhere in the app, which I
think GCC generates some startup code to register etc.
As Ondra pointed out, hashing is *not* done at message-send time; by
that time, the runtime environment already has a SEL in hand; there is
no method name in sight.
Yes, only in special cases are registration required to happen at
sending-time, e.g. when using setValue:forKey: -- however, in the above
I mean hashing the SEL pointer (not the name -- in fact the SEL pointer
is nothing more than a pointer to the name of the selector, but a
*unique* pointer, so no hashing is involved in registration AFAIK).
[...] I figured the class loader could go through the names of all the
methods in the class being loaded, generate new SELs as necessary for
method names we haven't seen before, and update the method-lookup
tables (the big ones I was talking about) for all classes that are
affected.
Okay -- you are correct about the first part, but it doesn't update the
tables. I think the main reason for this is, that since the table is a
hash, we want as few values as possible in the array, to minimize the
chance of clashes.
Another reason could have to do with performance, e.g. if I add an
NSString category, it needs to update tables for all classes being or
inheriting from NSString.
_______________________________________________
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.