Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75685
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU179-W318A2EE492D30DDB9FB009DEF50@phx.gbl>
References: <BLU179-W318A2EE492D30DDB9FB009DEF50@phx.gbl>
Date: Fri, 18 Jul 2014 09:43:56 +0200
Message-ID: <CAJWj5+EDcQxgZrq8Hi8GAt4nTzjaWnCtQfzyg7K_SfJxkqgt5g@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: simonsimcity@gmail.com (Simon Schick)

On Fri, Jul 18, 2014 at 7:02 AM, Theodore Brown <theodorejb@outlook.com> wrote:
>> Since I am very much in favour of scalar type hints, I've updated the
>> patch to master and made some minor improvements, and I am re-opening
>> the RFC with the intent to try and get it into PHP 5.7.
>
> First of all, this is my first reply on PHP Internals so I hope I am doing it right. :)
>
> Thank you very much Andrea for reviving this RFC - I'm really looking forward to using
> something like this in the next version of PHP to more easily define interfaces and
> catch unintended errors in my code.
>
> However, something I feel it is important to consider is not just how scalar type
> annotations fit into the history of PHP, but how they fit with the way type annotations
> are currently used and where the language is going in the future.
>
> A recurring comment I've heard in the discussion for this RFC is that strict type hints
> aren't "the PHP way." However, current type hints for classes, arrays, and callables
> work exactly in this way - they do not allow nulls, no casting is performed, and an
> invalid type results in a fatal error. If scalar annotations are introduced, many PHP
> developers (myself included) would naturally expect them to behave in the same way.
>
> Another concern I have is in regard to the future. I'm looking forward to the
> possibility of specifying nullable types in a future version of PHP (see Levi Morrison's "Declaring Nullable Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
> nullable types RFC is accepted, it would be highly disconcerting if scalar type
> annotations allowed null values regardless of whether a nullable marker is specified.
>
> I don't think that optional strict type annotations will take away from PHP's dynamic
> nature - they will instead be a valuable feature used in places where it is necessary
> to strictly validate a parameter's type - this is especially important to ensuring
> stability and accuracy in the large PHP applications it is my job to maintain.
>
> The RFC has already been updated to make boolean type annotations strict. Doesn't it
> make sense to treat the other scalar types in the same way? Perhaps a future RFC could
> propose a second (also optional) syntax to specify type annotations which perform casts.
> However, only having cast-based annotations for scalar types would be a mistake, IMHO.
>
> --
>
> Theodore Brown
>
> A PHP developer interested in the language's future
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi, all

First of all, thanks for all your time, you put into this thread! I
really am looking forward for a way, all can live with, because this
topic has followed the PHP community since the release of PHP 5.1,
since the introduction of type hinting for arrays
(http://php.net/manual/en/language.oop5.typehinting.php).

On an archive for this mailinglist I found threads that are going back
to 2005 (http://marc.info/?l=php-internals&m=112397232722668&w=2) -
Here's a list of all messages found:
http://marc.info/?l=php-internals&s=type+hinting&q=b

I've been one of the most active contributors to a thread back in 2012
- not the one giving most productive feedback, but the one giving the
most feedback ... (I later saw a statistic of who posted the most
mails to the mailinglist within the months of discussion)

What I see, we're again stuck with mainly three different opinions, as
Paul Biggar pointed out in his post - and he tried to find a solution
back then. I would suggest that anyone should read this mail - if you
want, read the thread - I haven't had the time for now..:
http://marc.info/?l=php-internals&m=124653792412529&w=2

In every round we took this topic, there have been new RFCs added ...
I don't know if there will be a solution, and my personal favorite is
the way, proposed in this RFC here. No casting for the values, just
more a validation - a lossy validation.

The main reason for this proposal is, that mostly every input to your
application will be a string. If it now is a file, a value from the
database, the GET and POST parameters, a CURL response - nearly
anything. I don't think it makes sense to first cast them before you
can use them.

I agree, that it feels wrong to have a method, accepting
(string)"123abc" and casting it to (int)123 for internal usage, but it
also feels wrong to not let the input (string)"123" pass as a
parameter to a method accepting integer. This would lead us to casting
(f.e. substr("string", (int)$var)  ), what again would be like accept
anything ($var = "abc").

I also saw some complaining about that older code may will not work
when introducing something here. As of what I think, this should be
implemented as an extension to the language as it is now. Old code
should be able to run as it is. You may will get a problem when your
old code is using a library, that you want to update and the library
is using the new syntax ;)

Thanks for reading.

Bye
Simon