Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: internals@lists.php.net
References: <72392123-d37b-26df-6886-218f48205f8a@fleshgrinder.com>
 <fab1b1a0-d920-4a68-7ca0-0a0dd9b82332@rhsoft.net>
 <6894aa94-0400-7a9a-f00c-47f1f556a4d0@php.net> <2241495.C7RNBcXJNU@vulcan>
Message-ID: <c126a971-f671-1dc8-384b-4338765996da@rhsoft.net>
Date: Tue, 26 Dec 2017 19:35:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <2241495.C7RNBcXJNU@vulcan>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
From: lists@rhsoft.net ("lists@rhsoft.net")



Am 26.12.2017 um 19:18 schrieb Larry Garfield:
> On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote:
>> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net:
>>> would you mind to explain this?
>>
>> "Foo|Bar", "array|string", etc. (still) make no sense to me.
>>
>> "scalar" makes sense to me although it is but an alias for
>> "bool|float|int|string".
> 
> If I may, I think the argument has always been that
> 
> 1) Foo & Bar makes total sense
> 2) int|float makes total sense
> 3) int & string is illogical so wouldn't matter anyway

not true

function x(int|string $x)
{
  $x = (int)$x;
}

$x can be simply from a database simply because without 
MYSQLI_OPT_INT_AND_FLOAT_NATIVE which is sadly not default you get 
everything back as string and so you can place the casting in the 
function instead of every single caller in strict_types mode while you 
don#t accept object, array or boolean here

why not cast a boolean here?

in case of the result of strpos() in the caller is false it likely 
should not call the function anyways but handle that error itself

> 4) Foo|Bar rarely makes sense but may sometimes, and its legality is an
> acceptable trade-off to get the first two.
> 
> In previous discussions it always seemed that people fixated on case 4 and
> ignored the usefulness of cases 1 and 2

as this is a programming language it's up to the user who writes the 
code in the language what is useful for his case - so if one is fixated 
on 3 or 4 because they would become possible the argumentation is 
strange anyways and "etc. (still) make no sense to me" is a personal 
opinion which hardly justifies a downvote at all unless there are real 
technical reasons

in my total valid usecase of 3) above in strict_types mode i must ommit 
the typehint at all or modify every single caller and that alone would 
justify unions