Added: Dec 1, 2008
From: h4ck3rm1k3
Duration: 6:55
http://www.perlfoundation.org/perl6 - - "continue" blocks don't share the same lexical scope even in Perl 5. But we'll solve this issue without "tunneling" in any case. (And we'll change the "continue" block into a "NEXT" block that goes inside, so we can refer to lexical variables from within it.) RFC: *Note that "try" is a keyword, not a function. This is so that a ";" is not needed at the end of the last block. This is because a "try"/"catch"/"finally" now looks more like an "if"/"elsif"/"else", which does not require such a ";", than like an eval, which does).* Again, this entire distinction goes away in Perl 6. Any expression block that terminates with a right curly on its own line will be interpreted as a statement block. And "try" is such an expression block. RFC: *$@ contains the current exception, and "@@" contains the current exception stack, as defined above under "die". The "unshift" rule guarantees that "$@ == $@[0]".* Why an "unshift?" A stack is most naturally represented in the other direction, and I can easily imagine some kinds of handlers that might well treat it like a stack, stripping off some entries and pushing others. Also, "@@" is a non-starter because everything about the current exception should all be in a single data structure. Keeping the info all in one place makes it easy to rethrow an exception without losing data, even if the exception was marked as cleanly caught. Furthermore I don't think that the exception stack needs to be Huffman coded that badly. So $! contains the current exception, and "$!.stack" accesses the current exception stack. Through the magic of overloading, the $! object can likely be used as an array even though it isn't one, in which case "@$!" refers to that stack member. The "push" rule guarantees that "$!.id == $![-1].id". RFC (speaking of the "exception" declaration): *If the given name matches "/::/", something like this happens:* @MyError: :App::DB::Foo::ISA = 'MyError::App::DB'; *and all non-existent parent classes are automatically created as inheriting from their parent, or "Exception" in the tail case. If a parent class is found to exist and not inherit from "Exception", a run-time error exception is raised.* If I understand this, I think I disagree. A package ought to able to contain exceptions without being an exception class itself. There certainly ought to be a shorthand for exceptions within the current package. I suspect they're inner classes of some sort, or inner classes of an inner package, or some such. RFC: *If the given name does not match "/::/" (say it's just "Alarm"), this happens instead:* @Alarm::ISA = 'Exception'; *This means that every exception class isa "Exception", even if "Exception::" is not used at the beginning of the class name.* Ack! This could be really bad. What if two different modules declare an "Alarm" exception with different derivations? I think we need to say that unqualified exceptions are created within the current package, or maybe within the X subpackage of the current package. If we have inner classes, they could even be lexically scoped (and hence anonymous exceptions outside the current module). That might or might not be a feature. I also happen to think that "Exception" is too long a name to prefix most common exceptions, even though they're derived from that class. I think exceptions will be better accepted if they have pithier names like X::Errno that are derived from "Exception": our class X:: Control is Exception; our class X::Errno is Exception; our class X:: NumericError is Exception; our class C::NEXT is X::Control; our class E::NOSPC is X::Errno; our class X:: FloatingUnderflow is X::NumericError; Or maybe those could be: c::NEXT e::NOSPC x::FloatingUnderflow if we decide uppercase names are too much like user-defined package names. But that looks strange. Maybe we just reserve single letter top-level package names for Perl. Heck, let's just reserve all top-level package names for Perl. Er, no, wait... ":-)" RFC 80 suggests that exception objects numerify to the system's *errno* number when those are available. That's a possibility, though by the current switch rules we might have to write CATCH { when +$ENOSPC { ... } } to force $ENOSPC to do a numeric comparison. It may well be better to go ahead and make the errno numbers into exception classes, even if we have to write something like this: CATCH { when X::ENOSPC { ... } }
Channel: Education
Tags: apocalypse larry perl perl6 wall
Rating: ( ratings) Views: 14 Comments: 0
