|
From: Joe E. <jen...@fl...> - 2008-12-12 17:40:00
|
Andreas Leitgeb wrote:
> Twylite wrote:
> > The counterpoints have already been presented. I think there are strong
> > arguments both ways,
>
> I'm definitely biased, but the only argument for handler-specific
> variables, that I found in the discussion was that all the other
> languages (especially Java) have per-handler variables.
>
> That one isn't strong in my mind. Did I miss other arguments?
Specific example:
try {
open $filename r
} on ok {fp} {
# ...
} on error {msg opts} {
# ...
}
(Which was one of the motivating use cases for dispatching
based on return code in the first place.)
With try/as, this would be:
try {
open $filename r
} as {xxx opts} on ok {
# (1) here $xxx is a file channel.
} on error {
# (2) here $xxx is an error message.
}
# (3)
For the sake of clarity, I'd want to use different variable
names in the two handler clauses -- "fp" for the case where
the result is a file channel, "msg" for the case where it's
an error message. (I can't think of a good variable name to
use in the "as" clause.)
At point (3), you know that $xxx and $opts are set to _something_,
but you don't know what. You usually don't care, either.
--Joe English
jen...@fl...
|