On 3/17/2012 10:40, Warp wrote:
>>>     "When the last reference to this timer dies, remove it from the runloop."
>> I will point you at Smalltalk, which had no trouble doing things like this. :-)
>    And exactly how does Smalltalk know what to do if you don't tell it?
> You have to be able to tell it somehow. It cannot guess it by magic.

The timer doesn't fire if you've garbage-collected it.

>    Because you have told the runloop to fire events with that timer on
> regular intervals. You have to tell the timer/runloop to stop doing that.
> The runloop owns the timer, so there's at least one pointer pointing to
> it until you explicitly tell the runtime to stop it.

Well, sure. So? I'm not following why this is a problem. If you want the 
timer to stop, you stop it.

>    Same goes for sprites in environments where you tell to the runtime
> (which might be eg. a custom game engine) "this object is placed here":
> The runtime owns the object and it will be there until you tell it to
> drop it.
>
>    How do you tell it to drop them when the last reference to them dies?
> With a destructor/finalizer.

You just told me the last reference will not go away, because it's in the 
runloop or the game engine, right? I'm not following.

It sounds like what you're saying is you want a type of object to keep 
reference counts, so when you dispose of an object, it can have an action 
other than finalizing other objects?  I.e., you don't want the timer garbage 
collected, but you want the timer to keep track of how many references to it 
exist from objects other than the owner, so it can be stopped when the last 
user gets collected?

In that case, you use weak references. The runloop would hold a weak 
reference to the timer, and when the last user of that timer gets collected, 
the timer gets collected out from under the runloop. Now, granted, you might 
want the timer or sprite to disappear before the next GC, if that's what 
you're talking about, but again that's not an appropriate task for a 
finalizer that only runs during GC in the first place.

The other question is whether you want the timer to keep alive the objects 
whose methods it invokes when the timer fires. In C++, you can delete the 
invoked object out from under the timer, but you can't do that in a GCed 
language. If you said "Run xyz.pdq() every ten seconds", then the xyz 
instance is going to hang around so it can be run, so asking how to stop the 
timer when nobody is run by it doesn't even make sense, from that point of 
view.

Do you want the fact that the sprite is on the screen to keep the sprite 
object alive? Or are you really saying "I want to use scope to keep track of 
when to start and stop various processes"

>    Why can't RAII *and* automatic GC be supported in the same language?

I think not so much RAII as reference counting. I fully support having weak 
references as well as reference-counted objects. (I think actually that 
Python supports both.) Reference-counted objects are high overhead compared 
to GCed objects, tho, so unless there's really a reason you promptly need 
them to free their resources, you probably want to avoid declaring your 
class that way. And if you manage to get a circular loop of 
reference-counted objects, your reference counting is going to be screwed up 
anyway, so all the more reason to mark reference-counted classes as special 
- you can have the compiler check that no reference-counted class can 
transitively point to an instance of itself.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message