Miko O'Sullivan aksed:
> .... what would "true" (the string) be converted to?
In a numeric context: 0 (as in Perl 5).
> Here's my point more
> explicitly: in a boolean context, there's no need to get any specific string
> (0, 1, "yup") as long as it correctly expresses true or false. It's when
> you convert a boolean into a string or number that it becomes convenient to
> define how they are represented by default. Yes, of course there are already
> ways to change a variable from [some representation of false] to 0, but by
> giving a slick way to default the string, a lot of ?? :: type stuff can be
> done away with.
Well, given that Perl 6 has an actual BOOL subtype, maybe C<true> and C<false>
could return objects with:
* a Boolean conversion to 1/""
* a string conversion to "true"/"false"
* a numeric conversion to 1/0
> That sounds like a great way to do it. A follow up question, then: would it
> be easy enough to accomplish that in a use-type format? I.e., something
> like I said earlier:
>
> use StrictBoolean TRUE=>1, FALSE=>0;
>
> or even just let it default:
>
> use StrictBoolean;
Yes. In Perl 6 C<use> statements will, by default be lexical in effect.
The module itself *might* look like this:
module StrictBoolean;
my @truth = ({TRUE=>1, FALSE=>0});
sub import ($class, *%beauty) { push @truth, \%beauty }
sub unimport { pop @truth }
sub true is exported { return @truth[-1]{TRUE} }
sub false is exported { return @truth[-1]{FALSE} }
> The issue of what is more intuitive is of course highly subjective, but I
> would argue that for several reasons the more concise version is more
> unituitive to the population at large:
Quite possibly. This is why I was so subjunctive about that option. And why
I'm happy to leave such decisions to Larry. His track-record on DWIMity is
exceptional. :-)
> - There's already a huge population of programmers out there who already use
> this notation. I frankly admit that I think of PHP as a great idea that
> wasn't done quite right.
I agree. Including that notation! ;-)
Damian