Robin Redeker writes: > On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote: > > I think, more importantly, they don't understand what they're > > getting in return for giving [refcounting] up. > > Could you point out what i get? > > I use TD is to handle resources: filehandles, database handles, gui > windows and all that. Refcounting does this with a little overhead, but > in a fast and deterministic O(1) way.
If it's deterministic behavior that you want, you probably ought to be doing things explicitly. What you get as a Perl programmer is, well, the ability to use circular data structure. Big deal, right? But if you're an extention writer, you get relief from days of refcount debugging and a nice fast throughput (though the former is what convinces me). Hacking on parrot is such a joy, because I can just forget that I need to free memory. > And how do you want to implement glib objects with parrot? They are > refcounted. How do you do it in Perl 5? Glib doesn't use Perl's refcounts, it uses its own right? (I don't actually know). But if the behavior of your program depends on where things are destoryed, and caching a reference somewhere can keep your window from closing, I'm under the impression that you should be doing it explicitly. Perl 6 in particular provides so many hooks that pure destruction-based program behavior is probably already too obfuscated. At least, that's my experience writing the ODE module. I initially had the destroy_body calls inside the destructor. But I found that bodies would magically disappear under my nose, and others would never go away. I ended up switching to an explicit destroy call, and now my life is much less painful. But that's my opinion. :-) Luke
