Re: RFC: Case package documentation

One or two targeted examples (e.g. for the "Modifying the dispatch table" section, or in the discussion of fall-through) would be useful; it's a bit dry the way it's written.
I am puzzled by the fact that for the smart case the dispatch table cannot be modified after it is created; this is sufficiently different from what I would expect from a dispatch table that it deserves further comment. (I would go as far as to classify it as a bug of sorts, even if it is not fixable.)
Does the default case need to be at the end of the case list? I gather that the answer to this is no, but either way it should be explicitly mentioned.
I think it is a design mistake to treat the specification of a smart range test as an unordered pair, because it is handy to know that a test of the form [$begin, $end], will be never be true when $begin > $end, which happens often when the endpoints are generated programmatically.

I could not make any sense out of this paragraph:

To smart-match against all elements of an array, you can include a
ref to the array as a testset (don't wrap it in [] ). To combine it
with other tests, make the action C<sub {Case::resume()}> and put the
rest of the tests as the next testset.
[download]

the lowliest monk

Comment on Re: RFC: Case package documentation Download Code

Replies are listed 'Best First'.
Re^2: RFC: Case package documentation by Roy Johnson (Monsignor) on Jun 02, 2005 at 22:46 UTC
I cannot think of a sensible way to make the smart-match dispatch table modifiable. With the string-table, there's no order of tests, so I can just stick the new test in without regard for where it goes. With the smart-match, there is an order of tests. Do you have suggestions for this? I think of modifying the table as a kind of nifty feature that is likely to be little-used. Why do you see it as important? The default case does need to be at the end of the list. I will make that explicit in the docs. You're probably right about treating ranges as unordered. That's actually a fix where I get to remove code. I had thought it would be a convenience. I also toyed with the idea of a reversed pair signifying "not between". But I don't think there's any value in that, either. The perplexing paragraph can probably be removed. It is in anticipation of people considering it a misfeature not to handle arrayrefs as arrayrefs. It merely points out that instead of `[ $arrayref ] => sub { something }, # if it handled arrayrefs as arra +yrefs` [download] you could actually do `$arrayref => sub { something } , # treat $arrayref as a list of te +sts` [download] and `# instead of [ $arrayref, 'foo' ] => sub { something }, # do this $arrayref => sub { Case::resume() }, [ 'foo' ] => sub { something },` [download] I greatly appreciate your comments. Caution: Contents may have been coded under pressure.	[reply] [d/l] [select]
Re^3: RFC: Case package documentation by tlm (Prior) on Jun 03, 2005 at 01:07 UTC
I probably overstated my point about the immutability of the smart match dispatch table. My negative reaction upon learning that this table could not be changed stemmed from the idea that one of the strengths of a dispatch table over a hard-coded battery of `if`-statements (or a `switch` statement in C, for that matter), is that the dispatch table can be modified during runtime. In fact, such a table can be built by the program from scratch (e.g. upon parsing a configuration file, for example). Therefore it comes as a let down to find something called "dispatcher" (which is strongly suggestive of a dispatch table) that cannot be modified at runtime. It really boils down to the nebulous concept of "programmer's expectations". My comments here are just one data point; you probably need a few more :-) . How about changing the name of the main function from "dispatcher" to "switch" (as I think you once had it)? In this way you would not be telegraphing an implementation detail that, in this case at least, turns out to be a bit confusing. the lowliest monk	[reply]