Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
Message-ID: <54233506.8080102@gmail.com>
Date: Wed, 24 Sep 2014 22:17:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEp07h9-mX3SdJPG0CRsjbr0ZKmPXsx=UjdEpUAT_kbM5VZXiQ@mail.gmail.com> <CAA8DMBv0GOwPjru=rzMijmZ+=4gvc6z1oHN6TNH0ohFSxBLWxA@mail.gmail.com>
In-Reply-To: <CAA8DMBv0GOwPjru=rzMijmZ+=4gvc6z1oHN6TNH0ohFSxBLWxA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Little switch improvement: get the used variable
From: rowan.collins@gmail.com (Rowan Collins)

On 23/09/2014 08:29, Sanford Whiteman wrote:
 >> The `get_the_used_switch_variable()` is just a placeholder, name can be
 >> changed to something natural...maybe a constant.
 >
 > I feel this has diminished utility once you consider that the "switch
 > variable" is actually an expression and could well include multiple
 > $variables. Plus there's also the pattern switch(true) { } where the
 > interesting variables appear in case statements. Hard for me to see
 > the justification, but maybe I'm missing it.  My $0.02...

Surely that makes it *more* useful - the switch statement never contains 
"multiple variables", it contains a single expression, the exact value 
of which is not discoverable to the programmer. A key property of switch 
statements is that the expression is evaluated only once, so the engine 
is already storing this value, it just needs to be put somewhere accessible.

Perhaps rather than a magic function or constant, though, the switch 
statement could be extended with an "as" argument, which would store the 
evaluated expression into a normal variable, allowing nesting, and 
easier optimisation of the engine where the feature isn't used. Thus you 
could write this:

switch( some_expression() as $switch_value ){
   case 1:
     do_something();
   break;
   //...
   default:
     throw new Exception('Undefined input: ' . $switch_value);
     break;
}

Which would be shorthand for:

$switch_value = some_expression();
switch( $switch_value ){
...


As it happens, I've been pondering my own proposed extension to 
switch(), after some of the discussion that came up from the 
standardisation.

Currently, switch always uses a "loose" comparison (==), so cannot 
distinguish between "case 3" and "case 3.0". Occasionally, it would be 
nice to switch on a strict comparison (===); but then I thought, why 
stop there? What if you could use switch with any comparison operator?

My idea is to give the switch() statement an optional "use" clause 
(since that's an existing keyword) containing a single comparison 
operator, like so:

switch ( $number ) use ( === ) {
     case 3:
         // ...
     break;
     case 3.0:
         // No longer unreachable! :)
     break;
}

But also:

switch ( $age ) use ( < ) {
     case 2:
         $type = 'infant';
     break;
     case 18:
         $type = 'child';
     break;
     default:
         $type = 'adult';
}

This would work well in combination with the "as" keyword:

switch ( calculate_age($birth_date, $departure_date) as 
$age_at_departure ) use ( < ) {
     case 2:
         $type = 'infant';
         $infants++;
     break;
     case 18:
         $type = 'child';
         $child_ages[] = $age_at_departure;
     break;
     default:
         $type = 'adult';
         $adults++;
}

As well as comparison operators, instanceOf might also be useful:

switch ( $product ) use ( instanceOf ) {
     case ProductInterfaces\Flight:
         // ...
     break;
     case ProductInterfaces\Accomm:
         // ...
     break;
     default:
         // ...
}

Bitwise operators might be interesting too, but then you're into more 
complex implementation, because you've got to evaluate the operator and 
cast the result to boolean before evaluating the case. So the 
restriction should probably be "any binary operator which evaluates to a 
boolean result".

Thoughts?

-- 
Rowan Collins
[IMSoP]