Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101460
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>
 <c126a971-f671-1dc8-384b-4338765996da@rhsoft.net>
 <58A5ABDF-AA25-46D4-83E7-4DE72E3DFF5E@gmail.com>
 <757270790.33iDQ9MZ2V@vulcan>
 <4b55eed1-8656-ff70-e4e9-ad5e40213405@rhsoft.net>
 <B1.F6.47595.E17F54A5@pb1.pair.com>
 <f48976dd-589f-e88e-37ba-38096c3a3602@rhsoft.net>
 <73.EE.47595.179574A5@pb1.pair.com>
 <50caeb2d-62b6-167d-726e-e0e11ea201f3@lsces.co.uk>
 <CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com>
Message-ID: <ca89282f-c96e-b595-9c12-d7b41b93357d@rhsoft.net>
Date: Sat, 30 Dec 2017 23:14:15 +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: <CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; 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 30.12.2017 um 22:55 schrieb Michael Morris:
> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote:
> 
>>
>> Not being able to vote, many of us have no option to complain about the
>> way things are going. Currently there seems to be several styles of PHP
>> form the nice and simple untyped version I moved to from very strictly
>> typed hard compiled code I'd been using up until then, through to
>> current code which is reliant on third party things like PSR and
>> Composer and expects only strictly typed PHP.
> 
> This is born of the fact that while ignoring datatype makes learning PHP
> easier, it makes using it harder - especially when testing.

and using type hints is completly opt-in at all

> Mark me as against union types. First, it places the burden of getting the
> type right on the calling programmer. Stock PHP code doesn't do this and if
> popular 3rd party libraries start doing this too much it makes the language
> harder to learn.

but the outcome is way cleaner because errors are not silently as it is 
now without using type-hints - anyways, you are not forced to use any 
type hints at all but the people which know how bad code works without 
care about are able to do so and without unnions that all is very limited

> Second it blocks this proposal, which is a way to give people who want to
> control types the ability to do so in their own code without creating BC
> breaks in PHP or interoperability problems with other libraries. Doing this
> requires declaring variable types as an OPTION.  The default type of a
> variable will be scalar.

that is not true - even if the syntax would be BC compatible the 
behavior won#t

> Under what I propose putting what is now a type hint on the function line
> will become a type declaration, and a casting operation will result if the
> wrong type is passed in. So
> 
> function foo( int $a ) {}
> 
> Obviously this path becomes unavailable to us with union types - and by
> comparison union types is an ineffective band-aid. The above is a shorthand
> for this
> 
> function foo ( $arg ) {
>    var int $a = $arg;
> }
> 
> When a variable is declared this way it will autocast any assignment to the
> declared type. The only way to get around this is redeclare the type

this is hard to optimize - just look at the optimizations of PHP 7.1

also this ship has sailed long ago as we now have type hints (and i did 
not understand at all why they where intoruced in 5.3 only for arrays 
and objects)

the point of union types is that you are not limited to "int or float or 
string" but can say "int or string both are OK, i hanlde that in my 
code" and so you can use strict_types with GET/POST or database results 
which are by defintion string but don't accept objects or arrays you 
can't handle proper

function test(int|string $x)
{
  $x = (int)$x;
}

currently without type-hints you have a "array to string conversion" 
insead fail and fix that at the caller where *obvisouly* nobody did 
realize that any random var froma request could be any array

this has to be checked *before* call a function with such invalid data