At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
>On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > > DESTROY would get called twice, which is VERY BAD.
> >
> > *blink*
> > It is? Why?
> > I grant you it isn't the clearest way of programming, but "VERY BAD"?
>
>package Nuclear
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote:
>
> Dan Sugalski wrote:
>
> > Plus there's nothing stopping you from having $obj->DESTROY in your own
> > code, though it may be inadvisable.
>
> It is (mainly) inadvisable because:
> 1. GC will call DESTROY when it collects the memory, s
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote:
> John Porter wrote:
> > James Mastros wrote:
> > > I'd think that an extension to delete is in order here. Basicly, delete
> > > should DESTROY the arg, change it's value to undef,...
> >
> > Huh? What delete are you thinking of? This is
Branden wrote:
> John Porter wrote:
> > > ...and trigger a GC that will get rid of the arg.
> >
> > No. Perl decides for itself when to do GC.
>
> The idea is to *allow* a programmer to explicitly destroy an object, for
> better (and sooner) resource disposal. The programmer wouldn't have to do
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote:
> The problem is when objects are shared by
> many variables. For example:
>
> $a = new Object();
> $b = $a;
> ...
> destroy $a; ## would call $a->DESTROY()
> ...
> $b->doSomething();## should die. Note
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote:
> As I wrote in the last post, this isn't what I'm talking about. I'm talking
> about destroying the object before the GC does.
Yah, so am I. I'm just saying that after the object is destroyed, don't
keep it around.
> Yeah, what about a na
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
> *) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > [snip about DESTORY predictablity not being neccessary]
> > You're probably right about that, Branden. Quite nice, but not
neccessary.
> Hmm, I'd have to say that predictability is very, *very* nice,
> and we shouldnt ditch it u
James Mastros wrote:
> On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> > Huh? What delete are you thinking of? This is Perl, not C++.
> Umm, perldoc -f delete?
>
> Come to think of it, this doesn't mesh purticularly well with the current
> meaning of delete. It does, however, wit
At 10:12 AM 2/14/2001 -0300, Branden wrote:
>David Mitchell wrote:
> > James Mastros <[EMAIL PROTECTED]> wrote:
> > > ... do refcounting (or somthing like it) for DESTROY to get called at
>the right
> > > time if the class (or any superclass) has an AUTOLOAD, which is
>expensive.
> > ... the above
John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
>
> Huh? What delete are you thinking of? This is Perl, not C++.
>
Agreed, definitely Perl is not C++.
> > ...and t
James Mastros wrote:
> On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> > Also, I think it would be valid for the programmer to explicitly say ``I
> > would like to DESTROY this object now'',
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the
James Mastros <[EMAIL PROTECTED]> wrote:
> [snip about DESTORY predictablity not being neccessary]
> You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ l
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
> Huh? What delete are you thinking of? This is Perl, not C++.
Umm, perldoc
James Mastros wrote:
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
> ...and trigger a GC that will get rid of the arg.
No. Perl decides for itse
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> David Mitchell wrote:
> > ... the above seems to imply a discussion that you only need to do
> expensive
> > ref-counting (or whatever) on objects which have a DESTROY method.
> > However, since you dont know in advance what class(es), if
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > ... do refcounting (or somthing like it) for DESTROY to get called at
the right
> > time if the class (or any superclass) has an AUTOLOAD, which is
expensive.
> ... the above seems to imply a discussion that you only need to do
e
James Mastros <[EMAIL PROTECTED]> wrote:
> The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
> do refcounting (or somthing like it) for DESTROY to get called at the right
> time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway th
At 06:35 PM 2/13/01 +, Nicholas Clark wrote:
> > This may be a naive question, but what is the benefit - aside from
> > consistency, and we don't need to rehash the litany on that - to AUTOLOAD
> > getting called for DESTROY? I've never actually seen any code that makes
> > use of it. I hav
At 10:32 AM 2/13/2001 -0800, Peter Scott wrote:
>At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>>Certainly AUTOLOAD gets
>> > called if DESTROY is called but not defined ... just
>> > like any other method.
>>The idea is [for Larry]
On Tue, Feb 13, 2001 at 10:32:26AM -0800, Peter Scott wrote:
> At 01:16 PM 2/13/01 -0500, James Mastros wrote:
> >On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> >Certainly AUTOLOAD gets
> > > called if DESTROY is called but not defined ... just
> > > like any other method.
> >The i
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>Certainly AUTOLOAD gets
> > called if DESTROY is called but not defined ... just
> > like any other method.
>The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
>do
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
>
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> like any other method.
Yes, its a classic autoloader mistake
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > James Mastros wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
[Note: that's a hypothetical quote.]
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> l
> James Mastros wrote:
>
> >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
I'm not sure what that means. Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
--
John Porter
On Tue, Feb 13, 2001 at 12:40:45PM -0500, Dan Sugalski wrote:
> At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
> >It's pretty hard (for me) to think of when you'd want an AUTOLOADed DESTROY,
> >since if you create /any/ objects of the class, DESTROY will be called.
> >"It isn't possible to AUT
At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
>On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
> >package foo;
> >use attrs qw(cleanup_sub);
> >
> > would be nice, but I don't know that he'll go for it. (Though it's the
> only
> > way I can think of to avoid AUTOLOAD bei
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
>package foo;
>use attrs qw(cleanup_sub);
>
> would be nice, but I don't know that he'll go for it. (Though it's the only
> way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard
At 17:33 12/02/2001 -0500, Dan Sugalski wrote:
>At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>>Couldn't we simply (for non-implementer values of simply) provide a way for
>>people to ask for finalization on an object ? Given that most of the time
>>it isn't needed, it wouldn't be too much of a
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
> >It *is* rare in OO perl, though. How many of the variables you use are
> >really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
> >forget that you need to count every scalar in
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
>It *is* rare in OO perl, though. How many of the variables you use are
>really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
>forget that you need to count every scalar in every array or hash, and
>every iteration over a blo
At 01:44 PM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >Yep, that's another issue, and one I keep forgetting about, though the fact
> >that we don't do predictable finalization on some objects isn't a good
>
>Yes, I know I pr
On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Yep, that's another issue, and one I keep forgetting about, though the fact
>that we don't do predictable finalization on some objects isn't a good
Yes, I know I promised to shut up until you come up with a spec, but
At 09:08 PM 2/12/2001 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> > >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > >
> > > > Perl needs some level of tracking for objects with finalization
> attached to
> > > > them. F
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >
> > > Perl needs some level of tracking for objects with finalization attached to
> > > them. Full refcounting isn't required, however.
> >
> >I think I've hea
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > >I think I've heard you state that before. Can you be more specific? What
> > >alternate system do you have in mind? Is this just wishful thinking?
> >
> > This isn't just wishful thinking, no.
>
>You
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >>On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >>
> >> > Perl needs some level of tracking for objects with finalization
On Mon, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar <[EMAIL PROTECTED]>
wrote:
>> It's reasonably obvious (which is to say "cheap") which variables aren't
>> involved with anything finalizable.
>
>Probably a simple bit check and branch. Is that cheap? I guess it must
>be.
Yes, but incrementin
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote:
> Perhaps. It's not rare in OO Perl which is coincidentally one area in
> serious need of a speedup. I suppose I'm warped by my own experience -
> all the code I see every day is filled with references and objects.
> That's probably not
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>>
>> > Perl needs some level of tracking for objects with finalization attached to
>> > them. Full refcounting isn't required, ho
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >I think I've heard you state that before. Can you be more specific? What
> >alternate system do you have in mind? Is this just wishful thinking?
>
> This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > Perl needs some level of tracking for objects with finalization attached to
> > them. Full refcounting isn't required, however.
>
>I think I've heard you state that before. Can you be more specific? Wh
Sam Tregar wrote:
> On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > Also, the vast majority of perl variables have no finalization
> > attached to them.
>
> That's true, but without static typing don't you have to treat them as if
> they did? At the very least you need to do a "is it an object with
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> Perl needs some level of tracking for objects with finalization attached to
> them. Full refcounting isn't required, however.
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just
At 11:36 PM 2/11/2001 -0500, Sam Tregar wrote:
>On Sun, 11 Feb 2001, Jan Dubois wrote:
>
> > However, I couldn't solve the problem of "deterministic destruction
> > behavior": Currently Perl will call DESTROY on any object as soon as the
> > last reference to it goes out of scope. This becomes im
On Sun, 11 Feb 2001, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external resources (
crossed to -internals
Jan Dubois:
> Not necessarily; you would have to implement it that way: When you try to
> open a file and you don't succeed, you run the garbage collector and try
> again. But what happens in the case of XS code: some external library
> tries to open a file and gets a failu
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
<[EMAIL PROTECTED]> wrote:
>On Sunday 11 February 2001 19:08, Jan Dubois wrote:
>> However, I couldn't solve the problem of "deterministic destruction
>> behavior": Currently Perl will call DESTROY on any object as soon as the
>> last referen
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Almost all refcounting schemes are messy. That's one of its problems. A
>mark and sweep GC system tends to be less prone to leaks because of program
>bugs, and when it *does* leak, the leaks tend to be large. Plus the
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > > If I change the way some objects are used so
> > > that I tend to create other objects instead of reusing the old ones, I'm
> > > actually not degrading GC performance, since its wo
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > If I change the way some objects are used so
> > that I tend to create other objects instead of reusing the old ones, I'm
> > actually not degrading GC performance, since its work is proportional to
> > live data. Right?
>
> Cor
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote:
>On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> > The less memory you chew through the faster your code will probably be (or
> > at least you'll have less overhead). Reuse is generally faster and less
> > resource-intensive than re
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> The less memory you chew through the faster your code will probably be (or
> at least you'll have less overhead). Reuse is generally faster and less
> resource-intensive than recycling. What's true for tin cans is true for memory.
At 04:09 PM 2/9/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > > 2. Work proportional to live data, not total data. This is hard to
> > > believe for a C programmer, but good garbage collectors don't have
> > > to "free" every allocation
Dan Sugalski wrote:
> At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > 2. Work proportional to live data, not total data. This is hard to
> > believe for a C programmer, but good garbage collectors don't have
> > to "free" every allocation -- they just have to preserve the live,
> > or
57 matches
Mail list logo
