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

Reply via email to