Re: @property problem
Re: @property problem
- Subject: Re: @property problem
- From: Jens Alfke <email@hidden>
- Date: Sun, 17 Feb 2008 15:06:33 -0800
On 17 Feb '08, at 12:03 PM, Sherm Pendley wrote:
Why would the parent's size be hard-coded? You can get the size of the
parent at run time, by dereferencing a couple of levels into isa.
All the
compiler would have to do is emit code that walks down isa to get the
parent's size, and add it to self to establish a base address. The
only
hard-coded offsets would then be relative to that base, for the
current
class' own ivars.
This has been done before, most notably in IBM/Apple's "SOM" runtime
that was used in OpenDoc in the mid-'90s. The main drawback is that it
becomes more expensive to access instance variables. Instead of
indexing off a constant offset from the object pointer, you have to
call a runtime function that returns a pointer to the class's ivars,
and index off that.
It also adds some complexity to both the compiler and the runtime, to
deal with the dynamic location of the ivars.
The "Fragile Base Class" problem is common to many object runtimes. C+
+ has it even worse, in that the normal vtable-based runtime makes it
impossible to add even *methods* to a base class without breaking
subclasses. It turns out that fragile methods are much more of a
problem than fragile instance variables; it's fairly easy to reserve a
few unused ivars in advance and use them later on. So Obj-C has been
able to work quite well in dynamic libraries, while C++ has usually
fallen on its face. But it's nice that this last restriction is now
lifted in the 64-bit environment.
(Scripting languages don't generally suffer from this. Most of them
store an object's ivars in a hashtable, which is much slower but much
more flexible, so you can do crazy stuff like adding ivars to
individual instances.)
—Jens_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden