On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> We can do better than equivalence testing for colors. Instead, try to
> match. Surely a *smart* match operator really is smart?
>
> $color ~~ '#FF00FF'
> ==
> $color ~~ 'magenta'
> ==
> $color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
etc., for some definition of color(). In fact, that's probably the
right thing to do, is to make color a pattern constructor. Then you
can even put it in signatures:
sub name(color('#FF00FF')) { "magenta" }
Whatever that buys you....
If we ditch my proposal, then we can write it as you did. But I feel
uncomfortable with that (thus the proposal), since you never know how
people may have overloaded ~~ for "dwimminess", and when you say:
sub print_colored ($color, $text) {
$color = do given $color {
when 'red' { Color.new('#FF0000') }
when 'green' { Color.new('#00FF00') }
when Color { $color }
default { fail "Unknown color" }
}
}
Though in this case it's not much of an issue, unless the red pattern
matches /#..0000/ or something, in which case you are losing
granularity. I guess the reason it makes me uncomfortable is that old
obsession of mine where things that look orthogonal ought to be, like
'red' (a string) and Color (a class).
Then again, would one expect:
$foo ~~ 'bar'
To be equivalent to:
~$foo eq 'bar'
Or not? I mean, that can be the string pattern's job, but then 'red'
and Color aren't really equivalent anymore.
/me punts patterns until he understands more.
Luke
