Re: Memory Management Mismanaged
Re: Memory Management Mismanaged
- Subject: Re: Memory Management Mismanaged
- From: Marcel Weiher <email@hidden>
- Date: Wed, 7 May 2003 09:53:28 +0200
I think that this retain count system is very bad for two reasons:
1. It is a barrier for new people. From the regular messages on this
issue I see in this group, it seems to be a difficult concept to
understand (I think so).
Actually, from the very same messages, I get the feeling that some
newbies make it much more difficult than it is, and have problems.
Others quickly grok just how easy it is, but you simply don't hear from
them...
It's like icon design - if you have to keep explaining to people how
that squashed bug on the screen is emblematic of your great magnum
opus, there's probably something wrong with your design - you
certainly can't (shouldn't) blame them. I think it is quite possible
that this has turned people off Cocoa as a whole, meaning that they
haven't had the great experiences of working with such rich tools,
and, possibly Mac development altogether. This is a shame.
There are also people who have difficulties groking Cocoa, usually for
the very same reason: they expect complexity where there is
simplicity. So let's throw out Cocoa!
2. It gets in the way.
a) You have to take care of the pointer objects in your objects with
the dealloc method.
Yup, that is still a hassle, but a fairly minor one. So minor, in
fact, that I am not using the automated technique I developed once in a
project. How did this automated technique work? Simple: use a list
of instance varible names and key-value coding to provide both fully
automated encoders/decoders and the dealloc method. The list can be
provided manually (control) or from the runtime (convenience).
b) You have to write special accessor methods
idAccessor( var, setVar )
Whew, that just killed me!
c) There is no standardisation of what these accessor methods should
look like (I use the three statement, retain, assign, release variety
for setting, but think that they may not be thread safe...).
Actually, that *is* the standard version. Of course, people are free
to use non-standard ones for whatever reasons, if it pleases them.
- If you have to take care of things yourself, is it any less work
than the standard C style do it yourself technique?
YES!
I think you are missing the crucial aspect of this reference counting
scheme: turning a really, really hard global problem into a series of
very simple local ones, and having most of the provided already doing
this. It makes a huge difference, as anyone who moved from
pre-Foundation to Foundation can confirm.
- It is definitely more work than an environment that has automatic
garbage collection.
It can be more work, sure. However, the amount of 'extra' work can
easily be reduced to be just about negligible in most cases. In fact,
writing accessors for objects is exactly the same amount of work as it
is for scalers, at least for me:
idAccessor( object, setObjecte )
intAccessor( count, setCount )
Or do you also advocate completely automatic accessors? That would be
a different subject...
Programming is about taking ideas that are in yours or others' heads,
sometimes specified in documentation (!), and creating code that
brings those ideas to reality. It is like, you are 'here', with the
ideas, and you want to be 'over there' where the program runs - like a
path. Anything that slows you down or side-tracks you just delays
delivery of the program.
Yes. They *should* also allow you to express your ideas almost in a
1:1 fashion, after you've defined the necessary pre-requisites. Todays
languages are miles away from this, but I find that Objective-C is
actually one of the truly better ones...
Memory management is something today's programmers should not have to
deal with.
The problem is that you *have* to deal with it, even if it is
automated. Drop by the Squeak list to see some of the issues (like
having to force a full GC in various situations where you need
resources freed immediately, like socket ports, and then having the
system really slow down for apps that generate a lot of sockets...)
- We have really powerful machines today and what do they do? Sit
around while we type in our code and wait for the bugs!
What's the solution? Well, Lisp since the sixties, Smalltalk since
the eighties, Java since the nineties, plus any number of other
languages have had automatic garbage collection...
And they all have language models that allow this. Objective-C does
not. Simple as that. Objective-C has always been a compromise, a
hack. I happen to think it's one of the greatest hacks around, and
part of its greatness comes from being a hack and making no bones about
it ('purity' debates are just so meaningless...). But it does mean
there are compromises, as with *all* languages.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
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.