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: "Sherm Pendley" <email@hidden>
- Date: Fri, 23 May 2008 04:30:50 -0400
On Thu, May 22, 2008 at 11:21 PM, Bill Bumgarner <email@hidden> wrote:
> On May 22, 2008, at 6:36 PM, Graham Cox wrote:
>
>> I think many of the additions in Object-C 2.0 and the addition of garbage
>> collection is *precisely* a case of changing Cocoa to resemble other
>> platforms (i.e. Java). Personally I don't find any of the new features all
>> that compelling, though they are no doubt worthwhile for many. Since veteran
>> Cocoa programmers have managed fine without any of these for a long time, I
>> can only deduce that these changes were added by Apple for the express
>> purpose of lowering the barriers to entry for programmers coming from a Java
>> or .NET background.
>>
>
> The design goals of properties and GC were to make Cocoa developers more
> productive
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.
> That the technologies lower the barriers to entry is certainly true and
> desirable, but that was secondary to the goals of the features.
Well, I certainly can't argue with you as to the goals - you're there and
I'm not. :-) But, goal or not, I think those particular features are *far*
more useful to Cocoa developers who are fairly new than they are to vets.
They don't get in vet's way either though, and they're *very* useful for
newcomers to Cocoa. So please don't get me wrong - I do think that including
them worked out well, even if it didn't work out exactly as planned.
Lowering the learning curve is a good thing.
> Of course, any improvements to a development environment that *don't*
> reduce complexity and *don't* make developer more productive is likely of
> questionable value.
Oh, properties and GC do reduce complexity. They do make me more productive.
My opinion of them is more ambivalent than negative - if you Sharked the
time I spend programming using "1.0" techniques, the time I spend on
accessors and GC would be near the bottom 5%. Sure, they solve the problem
they're intended to, and they do it well, but that problem just wasn't that
big a deal to me anyway.
Now, before this begins sounding *too* negative - I'm chomping at the bit to
support fast iterators in CamelBones. They can reduce the bridging overhead
of iteration from O(n) to constant time, and that's *huge* to me. And, of
course, as a Perl user I can't help but appreciate the choice of foreach()
to implement them. :-)
Properties are specifically designed to allow APIs to declare setter/getters
> with more precision within the interface and to reduce the amount of
> repetitive code required within the implementation. Properties were quite
> specifically designed to continue the generally fairly explicit delineation
> between interface and implementation.
All of which are great ideas that Accessorizer implemented years ago. :-)
> 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.
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?
Beyond being a great convenience and eliminating one of the most common bugs
> in Cocoa programming, GC was added because automating memory management is
> one of the best services that can be provided by the system to aid in the
> development of code that can take advantage of multiple cores, of which
> every macintosh now has.
Can't argue with that, but there's automation and there's automation.
Encapsulating "manual" memory management in accessors that are
script-generated counts, in my book, as being at least 98% automated
already. Gaining that final 2% is nice, but it's not, as Graham put it, all
that compelling.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
_______________________________________________
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