Re: How far with accessors?
Re: How far with accessors?
- Subject: Re: How far with accessors?
- From: Ondra Cada <email@hidden>
- Date: Thu, 27 May 2004 17:33:39 +0200
Marco,
On 27.5.2004, at 16:09, Marco Scheurer wrote:
>
I don't want to go back to the whole debate about the benefits (or
>
lack of them) of autoreleasing accessors, but this doesn't make sense
>
too me.
I would recommend to go back to it ;) to read it thoroughly -- the
reasons were explained there, umpteen times.
Presumed that in an ideal case, unless there are strong reasons
otherwise,
*** a vended object should remain valid in the scope of the current
autorelease pool *** ("the presumption")
the reasons are self-evident.
(Well I do know you and Marcel and probably more people don't think the
presumption is right. On the other hand, others, including at least
some of the Cocoa implementors themselves, do; the combination of an
autoreleasing setter and plain getter or otherwise is actually
recommended in the docs. Therefore, let's decide anybody for himself.)
>
otherwise I see no reasons why your dealloc should use autorelease
>
instead of release
Namely: if you don't use autoreleasing getter, you have to use
autoreleasing setter and dealloc both *so as to fulfill the
presumption* (of course you may NOT WANT TO, but that's a different
question).
>
as you know in my opinion, not less robust
Also in the sense of the presumption (and only in this sense) is the
autoreleasing getter definitely more robust, for it ensures the
presumption in wider scope of situations (namely, in case the setter is
used inside of a nested autorelease pool).
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.