Darren New <dne### [at] sanrrcom> wrote:
> >    "When the last reference to this sprite dies, remove it from the screen."

> I will point you to Smalltalk, which had no trouble doing things like this.

> >    "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.

> >    And so on. (Actual real-life examples.)

> Again, you seem to be assuming that the OS isn't garbage collected. If you 
> just GCed the timer, why would it still be firing events?

  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.

  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.

> No, if you don't implement GC in the OS, you need finalizers to tell the OS 
> that you're done with a resource. If you *do* implement it in the OS, the OS 
> knows you're done with the resource because it knows there aren't any more 
> references to the resource.

  But not everything is a system resource.

> That said, your idea of COW is an interesting case. I remember you talking 
> about it before. And I'll grant that it's not the sort of thing that's 
> trivial to do without keeping track of how many references there are to the 
> object. But I'd rather see this as something like a different type of class, 
> rather than taking advantage of a more global functionality designed to 
> bypass limitations in the OS. In other words, your COW doesn't really need 
> finalizers. It needs a way of knowing how many references there are to your 
> writable block, whether it's already shared.

  I can't think of any other way of knowing if an object is being shared
than by either using deterministic scope-bound reference counting, or by
running a GC sweep, which would ostensibly be extremely heavy if done too
often.

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

-- 
                                                          - Warp

Post a reply to this message