yoda 2

2000-08-16 Thread David L. Nicol
=head2 eval/die remains perfectly workable Perl5 has a perfectly agile exception handling method, C, which syntax-checks at compile time and returns the value of the value of the last expression evaluated and sets the special error variables in cases of errors. We leave that alone, and use it f

Re: error handling and syntax extension

2000-08-16 Thread David L. Nicol
or AUTOLOAD can be defined in terms of C and overloaded that way, rather than being its own kind of magic. catch "AUTOLOAD-$classname-$polymorphicsignature" {... Jonathan Scott Duff wrote: > > On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote: >

AUTOLOAD in terms of throw

2000-08-17 Thread David L. Nicol
Graham Barr wrote: > > On Wed, Aug 16, 2000 at 04:49:15PM -0500, David L. Nicol wrote: > > > > > > or AUTOLOAD can be defined in terms of C > > and overloaded that way, rather than being its own > > kind of magic. > > > > catch "AUTOLOA

yoda 2 clarifications Re: AUTOLOAD in terms of throw

2000-08-17 Thread David L. Nicol
will not return. Glenn Linderman wrote: > > "David L. Nicol" wrote: > > > What I was suggesting was, if you want to overload the autoloading > > of something, it could be done with "catch" instead of rewriting > > t

background reading

2000-08-17 Thread David L. Nicol
Peter Scott wrote: > >Maybe $! becomes an alias for anything that gets thrown > > Actually it looks like $@ is doing that at the moment. *Confused* Make them all writable, then we can make user-defined errors seem to be whatever we want. Or leave them the hell alone and introduce a new var

Re: Draft 3 of RFC 88 version 2.

2000-08-22 Thread David L. Nicol
> Does this cover all the cases? > Does it allow not only die but everything w/in Carp.pm to be implemented in terms of it? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Laziness with responsibility http://www.tipjar.com/kcpm

Re: $a in @b (RFC 199)

2000-09-14 Thread David L. Nicol
'John Porter' wrote: > > David L. Nicol wrote: > > "Randal L. Schwartz" wrote: > > > > > > I think we need a distinction between "looping" blocks and > > > "non-looping" blocks. And further, it still makes sense