On Fri, Jan 26, 2001 at 02:08:01PM -0600, Garrett Goebel wrote:
> Discussion of RFC 271 and 194 on pre and post handlers for subroutines
> reminded me of Larry's desire for Perl 6 to support the coexistence of
> different versions of modules.
>
> Besides http://dev.perl.org/rfc/78.pod, are there
On Wed, Feb 14, 2001 at 07:40:26PM -0700, Tony Olekshy wrote:
> The problem may be that a dynamic always statement means both
> "no matter what happens" and "not until later". The static
> finally clause just means "no matter what happened" (the effect
> is immediate).
I'm fond of post, myself.
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
> >
> > If we take this approach then we know exactly what the following
> > code will do.
> >
> > { my $p = P->new();
> >
> > $p->foo and always { $p->bar };
> >
> > except Error::IO { $p->baz };
> > }
> >
> > We also know when
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Traditionally Perl has had both the "do" and the "eval" block
> > forms, the latter which traps, the former which doesn't.
>
> In the perl 5 pocket reference 3rd edition page 63, it claims that
> $@ is set to the result of an eval or do. How
"David L. Nicol" wrote:
>
> Tony Olekshy wrote:
>
> > If we take this approach then when you just want to casually say
> >
> > my $f = open $file; always { close $f };
> >
> > you can. I like that. In addition, [...]
>
> How about "later" instead of "always"
>
> Because: "later" is a time in
Nicholas Clark wrote:
>
> my $f = open $file or die "can't open $file";
>
> is troublesome. It doesn't report *why* the file can't be opened.
>
> [...] *flexible* exceptions are needed
The first version of RFC 88 didn't care what exception objects
were, but discussions in the errors mailing lis
Peter Scott wrote:
>
> > try {
> > die "foo";
> > } catch {
> > die "bar";
> > }
> >
> > [...]
>
> Surely the first one catches it cleanly since it has a
> "catch-all" catch clause.
That "catch-all" clause throws. In RFC 88 we said, in the
Definitions section,
Dan Sugalski wrote:
>
> Tony Olekshy wrote:
> >
> >I think we need to provide some way for developers to explicitly
> >specify predictable end-of-block cleanup (using something like an
> >always block or finally clause).
>
> Attributes or other things stuck on the end of blocks strikes me as
> a
> 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
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,
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?
After lurking on the Perl6-lists and finally catching up on this long
discussion about garbage collection, I'm coming out ;-).
The reason I'm coming out is that I realised that we should maybe have a
radically different view on garbage collection than we have now.
Think about it:
1: in an ide
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 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
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 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
[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
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
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: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 { ... }
> > > > >
>
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
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
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
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
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
[[ 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: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
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
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.)
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
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
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
[[ 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
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
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
Folks, I would really appreciate it if we could all hold off on discussions
of garbage collecting for a little bit. We're all getting sloppy with
terminology, and fuzzy with what does what and when.
I should have a first cut of the garbage collection and object cleanup PDD
by the end of the we
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
On Wed, Feb 14, 2001 at 02:52:35AM -0800, Ask Bjoern Hansen wrote:
> I made a simple list of what we have so far at
> http://dev.perl.org/ppd/
Magic! Thanks very much!
(And for all the rest of the perl.org work, natch... :)
--
"It is easier to fight for principles than to live up to them."
--
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
On Sun, 11 Feb 2001, Simon Cozens wrote:
> Ask, could we have the PDDs placed up on dev.perl.org in the
> same way as the RFCs, please?
I made a simple list of what we have so far at
http://dev.perl.org/ppd/
- ask
--
ask bjoern hansen - http://ask.netcetera.dk/
On Wed, 14 Feb 2001, Simon Cozens wrote:
[...]
> If you think it would be ethical and correct for the assistants to draw
> a salary while the editor does not, please go ahead and push O'Reilly
> for money.
I want a cent per mail delivered from the perl mailinglists![1] Who
want's to pay?
(In o
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
> - Mailing list organization (creating new lists when necessary, etc..)
I'm always happy to take care of that. Just mail me at [EMAIL PROTECTED],
or better at [EMAIL PROTECTED] if you manage to remember that
address.
Experience shows that the ma
53 matches
Mail list logo
