Re^2: RFC: Case package documentation

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.

Comment on Re^2: RFC: Case package documentation Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]