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 21:57:47 +0200
On Tuesday, August 6, 2002, at 09:31 , Marco Scheurer wrote:
On Tuesday, August 6, 2002, at 07:01 pm, Ondra Cada wrote:
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 ;)
OK, let's hope we do not shift to dialectics and a debate about the
definition of an accessor.
Well, I hope too, but on the other hand, so as we can reasonably speak
about "how to make an accessor", we must agree what accessor is, I guess.
Particularly, I am afraid the difference between owned (like window title)
and referenced (like window delegate) object is very important, and not
stressed out enough in Cocoa (the more so since for both are often used
the very same operations).
With this distinction on mind, it should be emphasized we are speaking of
accessors to owned objects here.
Here are more reasons not to use the [[object retain] autorelease]
pattern for a getter, and this time, performance related:
1) Collections are excluded from the pattern for performance reason. Most
would say that performance is not an issue for [window title]. How do you
decide for [person name] ? There is no way, as the framework provider to
know how person objects will be used.
I don't think so. In my opinion, there are other, much more important
design questions, which determine whether those Person instances will be
used in thousands and hundreds of thousands like containers (or, say, EOF
objects), or in tens or very low hundreds at worst (like cells, views or
windows). That way, the class design determines the usage -- and the
accessors should be appropriate, too.
2) If you use the [[object retain] autorelease] pattern, you make
profiling difficult. The performance penalty is not just the cost of
sending the retain and autorelease messages, but also the time spent
managing the autorelease pool.
Agreed, but it is a fair price. Nevertheless, the penalty is not that bad
-- looks like 45:64 in my testing.
3) If you use the [[object retain] autorelease] pattern, and it turns out
to be a performance issue, you make optimization difficult. Once you've
used that pattern, you are stuck with it, or else client code (not
necessarily yours, of course) could break. So you put the burden of
optimization on the client, who might see some improvements by using
nested pools, but who might end up writing a category to speed up your
accessor.
;) Well, you put *some* burden on the client anyway. Either potential
crash, or the potential slowness. I still claim that the former is much,
much worse.
And do please also consider that for the reasons I've stated before (with
generic complex classes you don't and can't know which actions might have
the side effect of using setter), to be sure that the crash would not
occur the client would *HAVE TO* retain/autorelease (or
retain/NS_DURING..NS_ENDHANDLER/release) almost any time the getter is
called anyway.
---
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.