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: Fri, 23 May 2008 16:45:07 +0800
On Fri, May 23, 2008 at 4:30 PM, Sherm Pendley <email@hidden> wrote:
> Obviously - but *which* Cocoa developers? I suspect that many veterans would
> categorize these additions as premature optimization - I can't speak for
> anyone else, but it's been years since I needed to write an accessor method
> by hand, or put a significant amount of thought into memory management.
This veteran really likes GC. It's delightfully liberating not to have
to think about memory management. Of course retain/release is not a
great deal of effort in the first place, but it's great to have that
bit of mental overhead go away.
The irony, of course, is that my day job involves doing lots of
realtime audio processing with Objective-C code, thus completely
eliminating any possibility of using GC. But I'll be using it for any
projects where I can get away with it.
For the rest, I can take it or leave it. They're mildly nice but not
compelling and I have a hard time figuring out why Apple has decided
to refer to *this* particular set of ObjC additions as "2.0".
>> Under the 64 bit runtime, properties can also be used to synthesize the
>> storage associated with a particular property.
>
> Does this work like "inside-out" objects? What I'm referring to is a concept
> found in some Perl OOP modules, to work around its lack of access limiters
> such as "private" or "protected." For each property, a hash (a dictionary,
> in Cocoa lingo) is created, and accessor methods that store and fetch values
> from it, using the object itself as the key.
It's much simpler than that. Class sizes are simply looked up at
runtime rather than at compile time, which means that a subclass no
longer needs to know the size of its superclass when it's built.
> 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. As far as I know even this is
not currently allowed by the language, though.
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