Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Message-ID: <54B6BCEC.1080504@mabe.berlin>
Date: Wed, 14 Jan 2015 20:01:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
In-Reply-To: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: dev@mabe.berlin (Marc Bennewitz)

Hi Andrea,

I have some notes about this RFC from a users POV with only little 
knowledge about internals.
I didn't read 100% of the theads of this RFC so I'm sorry if some notes 
of this email was already discussed.


1. Inconsistencies of ZPP and explicit casts

In my opinion it should be the same if you call a function in weak type 
mode and calling a function in strict type mode with explicit cast.

But that would require to remove inconsistencies of ZPP and explicit casts.


2. Only one choice for the language

In my opinion scalar types should be hinted strict and the caller of an 
API have to be sure to pass the right types. The caller have to know 
about the function he calls and he already should know what the function 
expects. This is the point were the caller have to know the type of an 
expected argument and he should know his own types. So he is the one how 
can pass the variable or make an explicit type cast.

To do so see [1]


3. Reserved words

I don't like it adding so much reserved words.
As I understand it correctly the reservation is because of naming 
collisions on type-hints with scalars and classes/interfaces.

Why not adding these types as classes (marked final and not allowed to 
be initialized for know)?

Than you can use the already existing standards of classes as type-hints.
This would allow you using your own class of a different namespace with 
the same name and would reduce BC break drastically.
The only consequence would be that you have to reference the root 
namespace or import (use) the classes of the root namespace to use the 
type-hints.
As sugar it should be possible to use inheritance and polymorphism to 
better hint what you really need.

E.g.: class Integer extends Scalar implements Numeric


4. Only one naming

I dislike the proposed aliases. The type names should be defined once 
without aliases and the manual and error massages should be changed to 
be consistent.

Because of PHP internally already allows different names this should 
persist to be BC safe but should be reviewed and documented what is the 
real type name and what are aliases. The aliases could be deprecated in 
another RFC.

Btw. The type float is used also as double and real. I don't see if 
these aliases are supported in your RFC or not.


Marc


Am 14.01.2015 um 01:16 schrieb Andrea Faulds:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significant revision to the RFC, so it’d be sensible to separate discussion of the updated RFC from the v0.1 RFC.
>
> Please tell me your thoughts.
>
> Thanks!
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>