Why won't this work:
As I see it, we can't guarantee that DESTROYable objects will be DESTROYed
immediately when they become garbage without a full ref-counting scheme. A
full ref-counting scheme is potentially expensive.
Even full ref-counting schemes can't guarantee proper and timely
destr
[[ 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
At 11:03 AM 2/14/2001 -0500, Buddha Buck wrote:
[Truly profound amount of snippage]
>I'm sure this idea has flaws. But it's an idea. Tell me what I'm missing.
You've pretty much summed up the current plan.
Dan
--"it's
After a week's delay where I've just been too busy,
I thought I'd resurrect the corpse of a thread I was involved in.
First off,
on Wed, 07 Feb 2001 14:37:33, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:05 PM 2/7/2001 +, David Mitchell wrote:
> >Dan, before I followup your reply to m
On Wed, Feb 14, 2001 at 06:37:18PM +, David Mitchell wrote:
> Hmm, there doesnt seem to be anything related to handling constants in PDD 2.
I anticipate constants will be PMCs with a small vtable of "get methods",
possibly with several different types of value (string, numberic, float, etc.)
On Wed, Feb 14, 2001 at 11:26:00AM -0500, Dan Sugalski wrote:
> At 11:03 AM 2/14/2001 -0500, Buddha Buck wrote:
> [Truly profound amount of snippage]
> >I'm sure this idea has flaws. But it's an idea. Tell me what I'm missing.
>
> You've pretty much summed up the current plan.
I have a strong
[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it co
On Wed, Feb 14, 2001 at 11:38:58AM -0800, Damien Neil wrote:
> sub do_stuff { ... }
>
> {
> my $fh = IO::File->new("file");
> do_stuff($fh);
> }
>
> In this code, the compiler can determine that $fh has no active
> references at the end of the block
No, it can't, but it can certai
Simon Cozens wrote:
> On Wed, Feb 14, 2001 at 11:38:58AM -0800, Damien Neil wrote:
> > sub do_stuff { ... }
> >
> > {
> > my $fh = IO::File->new("file");
> > do_stuff($fh);
> > }
> >
> > In this code, the compiler can determine that $fh has no active
> > references at the end of the
At 05:57 PM 2/14/2001 -0300, Branden wrote:
>Simon Cozens wrote:
> > On Wed, Feb 14, 2001 at 11:38:58AM -0800, Damien Neil wrote:
> > > sub do_stuff { ... }
> > >
> > > {
> > > my $fh = IO::File->new("file");
> > > do_stuff($fh);
> > > }
> > >
> > > In this code, the compiler can det
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
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 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
At 08:29 PM 2/14/2001 +, Graham Barr wrote:
>On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> > At 05:57 PM 2/14/2001 -0300, Branden wrote:
> > >Simon Cozens wrote:
> > > > On Wed, Feb 14, 2001 at 11:38:58AM -0800, Damien Neil wrote:
> > > > > sub do_stuff { ... }
> > > > >
>
On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> Yes it can tell, actually--we do have the full bytecode to the sub
> available to us, along with whatever metainfo we choose to remember
> generally about the sub. Whether we use the info is a separate matter, of
> course.
What ab
At 08:59 PM 2/14/2001 +, Graham Barr wrote:
>On Wed, Feb 14, 2001 at 03:38:55PM -0500, Dan Sugalski wrote:
> > At 08:29 PM 2/14/2001 +, Graham Barr wrote:
> > >On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> > > > At 05:57 PM 2/14/2001 -0300, Branden wrote:
> > > > >Simon C
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
> package NuclearReactor::CoolingRod;
>
> sub new {
> Reactor->decrease_core_temperature();
> bless {}, shift
> }
>
> sub DESTROY {
> Reactor->increase_core_temperature();
> }
A
On Wed, Feb 14, 2001 at 05:43:31PM -0300, Branden wrote:
> 4. Why should we bother destroying an object before GC does it?
>
> To free system resources, like open files or database connections. Probably
> the average program won't do it never, but programs that must open several
> files sequentia
On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> At 05:57 PM 2/14/2001 -0300, Branden wrote:
> >Simon Cozens wrote:
> > > On Wed, Feb 14, 2001 at 11:38:58AM -0800, Damien Neil wrote:
> > > > sub do_stuff { ... }
> > > >
> > > > {
> > > > my $fh = IO::File->new("file");
> > >
On Wed, Feb 14, 2001 at 03:38:55PM -0500, Dan Sugalski wrote:
> At 08:29 PM 2/14/2001 +, Graham Barr wrote:
> >On Wed, Feb 14, 2001 at 03:04:40PM -0500, Dan Sugalski wrote:
> > > At 05:57 PM 2/14/2001 -0300, Branden wrote:
> > > >Simon Cozens wrote:
> > > > > On Wed, Feb 14, 2001 at 11:38:58AM
I want to share my experience of garbage collection of the Java virtual
machine.
There are two common types of garbage collection, the agressive reference
count based and everything else.
The reference count system can garantee the quick response to memory
release. In such a system, we can safel
On Wed, Feb 14, 2001 at 01:24:34PM -0800, Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember?
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens wrote:
> > Using object lifetime to control state is almost never a good idea,
> > even if you have deterministic finalization.
>
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy,
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Hong
24 matches
Mail list logo
