Re: Efficient object wrappers and GC
Re: Efficient object wrappers and GC
- Subject: Re: Efficient object wrappers and GC
- From: Buddy Kurz <email@hidden>
- Date: Fri, 11 Apr 2008 10:25:38 -0700
I'm wondering if it would make sense (or be possible) to override -
retain and -release to increment/decrement your own variable in
addition to using the inherited behavior. In the GC environment, the
inherited retain does nothing but in either environment your
enumerator can detect the retain by checking your variable.
On Apr 11, 2008, at 9:53 AM, Alastair Houghton wrote:
On 11 Apr 2008, at 16:07, Michael Ash wrote:
On Fri, Apr 11, 2008 at 6:04 AM, Alastair Houghton
<email@hidden> wrote:
Under GC, these kinds of tricks are no longer possible because
there is no
-retain call any more, so no way to tell if it is safe to re-
initialise and
return the same wrapper object.
Aside from re-implementing the data structure itself in ObjC and
making all
of its nodes objects, which might not be possible in some cases,
has anyone
thought of an efficient solution to this problem when running
under GC?
The obvious technique would be to stop trying to make the
optimization
implicit and to make it explicit and managed by the caller instead.
In
other words, you write your API so that it explicitly returns the
same
object every time you call -nextObject, just with a new state. Then
you have a copy method which the caller can use to get a new
unchanging object for the case where he wants to keep one around.
Yes. It's a shame though because that doesn't really fit with the
way people expect NSEnumerator to behave.
I was really just wondering if someone else had had some stroke of
genius and come up with a way to do this kind of thing under the
GC. Or if, perhaps, it would be worth asking for some new feature
as part of the GC to help with this kind of problem.
(As I think I mentioned, I'm not actively using the GC in production
code right now, so this isn't important yet... it's just something I
thought of.)
Kind regards,
Alastair.
--
http://alastairs-place.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
_______________________________________________
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