On Wed, Feb 27, 2002 at 10:11:13AM -0800, Austin Hastings wrote: > > > C<when> is a conditional like C<if>, not a topicalizer. > > Right, it's a topicalizee, the victim of topicalization. And so it uses > $_ or $x or $! or whatever the current topic is.
i.e. a "defaulting construct" or "topic sensitive keyword". I like the latter, in this case, because it expresses what C<when> defaults to. > But inside, you have to KNOW what the topic is again, you can't just > use the default variable(s), so that differentiation of > > for @logged_exceptions -> $e { > when .survivable { if $e.isa('Exception::PEBKAC') { ... } } > } > > versus > > CATCH { > when .survivable { if $!.isa('Exception::PEBKAC') { ... } } > } > > becomes necessary. > > What I'm trying to suggest is that C<when>, because it already is doing > some special things (huge list of conditionals to try, implied 'next'), > is an orthogonal code element. It really IS going sideways, and unless > you are coding sideways (using C<given> or C<CATCH>) the when-block > represents a context-switch at the developer level. > > To that end C<when> should, when (urg!) used in a loop or other > straight-ahead construct to check the current topic, force the current > topic to become the default. I absolutely agree with the problem you're trying to solve. The "when ..survivable" vs. "if $e.isa..." distinction bothers me as well. But I'm greedy. I don't want to treat the symptom by adding to the list of ways that C<when> is weird. I want a systematic solution for the whole language. To me that means taking a step back from the familiar, but limiting, concept of "$_ is default". Exactly how that will work out, defaulting to topic everywhere, flagging the variable with an "assumed" property, or something else entirely, I'm not sure. But however it's done, I want it to be consistent in the bigger picture. Allison