On Wed, Apr 27, 2005 at 03:59:05PM -0600, Luke Palmer wrote:
> 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?  

Well, i and the people i know don't think that collection of circular
data structures gives much.

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

Memory is everything that you can forget. A pure GC costs you automatic
resource management. Right: A GC is for memory management.

> 
> > And how do you want to implement glib objects with parrot?  They are
> > refcounted.
> 
[..]
> I ended up switching to an explicit destroy call, and now my life is
> much less painful.

Well, i don't want the explict destrutor-calling hell you have in java.
Some thing i just don't want to do explicit: Filedestruction for
example. And what if my class manages a database handle? do i have to do
something like:

$my_cool_handle_obj->free_my_resources (); ?

This would be manual memory management:

   {
     my $s = malloc CoolClass;
     ...
     free $s;
   }

And with explicit resource handling (without timely destruction) it may be:

   {
     my $s = new CoolClass;
     ...
     destroy $s;
   }

Not that big difference. And this is what we have with
refcounting/timely destruction:

   {
     my $s  = new CoolClass;
     ...
   }

It's just that in my opinion timely destruction isn't something people
use rare. It's a do-what-i-mean feature. And wasn't that a feature of
perl6?

I don't know whether most/many people think that timely destruction is
something that we don't need much.

But it lets you forget memory management AND resource management.

And if Leopold and Dan and others think we can get efficent timely
destruction with this, and it works, and it's fast, 
i'm completly fine with it.

> 
> But that's my opinion.  :-)
> 

And this is mine ;)


cu,
robin

-- 
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker

Reply via email to