Re: Properties & GC (was Re: Cocoa et al as HCI usability problem)
Re: Properties & GC (was Re: Cocoa et al as HCI usability problem)
- Subject: Re: Properties & GC (was Re: Cocoa et al as HCI usability problem)
- From: "Michael Ash" <email@hidden>
- Date: Sat, 24 May 2008 18:51:51 +0800
On Fri, May 23, 2008 at 5:11 PM, Sherm Pendley <email@hidden> wrote:
> On Fri, May 23, 2008 at 4:45 AM, Michael Ash <email@hidden> wrote:
>>
>> On Fri, May 23, 2008 at 4:30 PM, Sherm Pendley <email@hidden>
>> wrote:
>>
>> > Does this sound similar? Objective-C obviously already has access
>> > limiters,
>> > but disassociating the object and property storage would eliminate the
>> > last
>> > remnants of the fragile base class problem. It would also allow
>> > categories
>> > to add ivars, would it not?
>>
>> Categories could only add ivars if they were loaded at the same time
>> as the main class, otherwise they could change the size of already
>> instantiated objects which is Very Bad.
>
> That's just the problem that inside-out objects would solve! With the ivars
> stored separately from the isa pointer, adding an ivar would simply add
> another ivar storage dictionary to the heap. Since inside-out objects are
> nothing more than keys into the ivar storage dictionaries, adding another
> dictionary doesn't change the size of any objects past, present, or future.
It certainly would solve that problem, but the solution isn't free.
Dictionary lookups are significantly more expensive than a direct
memory load, especially when you make the dictionaries thread safe and
then pound on them a lot from multiple threads. Taking a lock every
time I access an ivar doesn't sound very fun to me.
This idea is commonly used explicitly to provide ivar-like things in
categories. And in fact with the addition of garbage collection this
becomes vastly easier to accomplish; your dictionary can simply be an
NSMapTable with weak keys, removing the need to do evil swizzling
tricks so you can know when objects get deallocated.
Mike
_______________________________________________
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