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
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
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
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
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
29 matches
Mail list logo
