Re: Accessor methods and (auto)release: conclusion
Re: Accessor methods and (auto)release: conclusion
- Subject: Re: Accessor methods and (auto)release: conclusion
- From: Ondra Cada <email@hidden>
- Date: Tue, 6 Aug 2002 19:01:17 +0200
On Tuesday, August 6, 2002, at 04:46 , Marco Scheurer wrote:
On Tuesday, August 6, 2002, at 03:59 pm, Ondra Cada wrote:
On Tuesday, August 6, 2002, at 03:03 , Marcel Weiher wrote:
...You have to, because for some reason (performance), collections are
excluded from the retain/autorelease pattern.
Yup. The point is, not to make us programmers to use those patterns unless
really necessary.
Nobody would object to that kind of code, and it is not different than
the "ugly" patterns above. So yes, I'm using these constructs, when they
are needed, not everywhere. I also try to rewrite the code so that they
are unnecessary, if possible.
(*) The reason it's not that easy is that container is just a container.
You do know what happens if you send it this or that message -- exactly.
Therefore, you can, for example, freely use something like
id o=[array objectAtIndex:3]; // presuming there's more objects, of course
... [array count] ...
[o whatever];
because you do know that nothing but explicit removing of object (or all
objects or the complete array) would render 'o' released. Normal classes,
on the other hand, are much more complicated. Although we might presume
that, say, -[NSWindow setFrame:] does not change its title, it still in
some special cases, for whatever godforsaken reason (eg. loosely connected
to some kind of automatic abbreviation) might!
More generally, with a normal non-just-container class, you just can't
know which method might internally use the setter. What's worse -- with
things like notifications, you even can't know whether a setter might not
be used as a sideeffect of some, at the first look, completely indifferent
action performed with some utterly independent object!
Therefore, you either would have to retain vended objects immediately
after getting them, or you should use those accessors which ensure that it
would never be a problem.
BTW, why is this retain/autorelease uglier here than in a getter? Because
in a getter it's more or less hidden, you can forget about it, while it
may be obfuscating a bit an algorithm code?
Nope. Because in the getter it is done just once and it works anywhere. On
the client side though you have to write it again and again anytime you
use the getter.
Now, since collections are definitely excluded from the accessor pattern
you advocate, your "invariant" does not hold either.
More or less it does, for it is questionable whether -addObject should be
called a setter and -objectAtIndex should be called a getter ;)
Sometimes (most of the times I would say) you have to use the "ugly"
construct anyway. What's the point then?
To be able to use them only when necessary (in my experience, by far not
most of the times), and, what's even more important, only in cases you can
reasonably say whether they are needed or not ((*) again).
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.