On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> This is pretty nitpicky. If it's in scope but you don't use it, then > it doesn't matter. Kind of like a Zen koan: if an object is collected > in the forest but nobody is pointing to it anymore, does it make a > sound? :) I'm just arguing that it makes it more straightforward if the GC behaves deterministically according to the code you wrote, rather than what the optimising compiler re-wrote for you. > Objects stay live for as long as you reference them, period. This is > what the collector guarantees and this is what the real-world behavior > is. The problem occurs when you try to reference their contents after > you stop referencing the objects themselves. The documentation says > nothing about scope, it talks about the stack. The stack is already an > implementation detail, so if you're going to examine that promise then > you absolutely need to examine those implementation details. I guess so! But it means that that promise is worth about as much as an inner pointer ;) >>> How would it be less straightforward? If it returned collected memory >>> then everything will Just Work for the common case of using the >>> pointer on the stack. You would also have the additional convenience >>> of being able to safely store the returned pointer in a __strong heap >>> variable, something which you simply cannot do under non-GC rules at >>> all. Looks like there are only improvements to me, where is the >>> problem? >> >> I agree with you that if it returned collected memory, it would be >> more powerful than under retain/release/autorelease. But power and >> straightforwardness do not always go hand in hand ;) > > Hmm, you didn't answer my question though. Where exactly is the > problem? For the case where the old-style rules also work, it would be > precisely as straightforward. (In case your objection is with the > __strong qualifier, note that you would not need that for a local > variable, only for instance variables.) Where is the problem with having NSData return collected memory? I have no problem with that, I just don't think it solves the whole problem. Now it's your turn -- where is the problem with the compiler marking references you have *semantically* placed on the stack as strong, whether or not they really end up on the stack after optimisation? > I disagree. Since the programmer cannot possibly know the state of the > call stack in any other way than by knowing that the compiler must > keep references to objects right up to the point where those objects > are no longer used, he must not make any assumption as to the lifetime > of those objects beyond that point. But who is to say the compiler won't make optimisations which alter when the object is last referenced? (See my reply to Peter for a code example.) Hamish _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
