Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80588
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: <54B824D9.7090601@mabe.berlin>
Date: Thu, 15 Jan 2015 21:36:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: internals@lists.php.net
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <54B6BCEC.1080504@mabe.berlin> <894A539A-1919-4368-8128-29863F411992@ajf.me>
In-Reply-To: <894A539A-1919-4368-8128-29863F411992@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)


Am 14.01.2015 um 23:39 schrieb Andrea Faulds:
> Hi Marc,
>
>> On 14 Jan 2015, at 19:01, Marc Bennewitz <dev@mabe.berlin> wrote:
>>
>> 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.
> Explicit casts and implicit casts have different behaviour, and that is definitely a good thing. Implicit casts can and should fail if the conversion isn’t sensible. Explicit casts aren’t supposed to fail.
That's a big problem for the strict type mode because of you have to 
explicit cast to pass function signature which would result in a much 
unsafer behavior were you originally wont a strict behavior. The only 
way to be safe would be to use extra function calls for casting.

>
>> 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.
> This is all very well and good, and strict typing has its advantages, but there are a lot of people who do *not* want to have to deal with a strictly-typed API.
It's only a personal feeling for scrict typing but it requires casting 
to be fixed.
But I have to agree with that casting is part of the caller with or 
without this choice.

The library author only defines the type he requires but the caller is 
the one have have to do so. Week typing in this case only helps the 
caller to automatically cast.

>
>> 3. Reserved words
>>
>> I don't like it adding so much reserved words.
> This doesn’t add any reserved words. It prevents the usage of some names for class names.
Preventing usage of some names means the same as reserved names at least 
in the contest of class names.

>
>> 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 now)?
> Because then you’d have to do this at the top of every single file:
>
> use php\typehint\int;
> use php\typehint\float;
> use php\typehint\string;
> use php\typehint\bool;
>
> Considering how much people seem to dislike the idea of using declare() for strict typing, I can see how poorly that would go down.
Such types should be on the root namespace. So the only difference would 
be a backslash and only if you are within a namespace.

And to reaped myself you can do vary useful:

// internal pseudo code
class Scalar {}
interface Numeric {}
class Integer extends Scalar implements Numeric {}
class Float extends Scalar implements Numeric {}
class String extends Scalar {}
class Array implements Traversable {}

// users code
function increment(numeric $num) { return $num + 1; }
function incrementInt(integer $int) { return $int + 1; }
function incrementFloat(float $float) { return $float + 1; }

// in namespace
function increment(\numeric $num) { return $num + 1; }
function incrementInt(\integer $int) { return $int + 1; }
function incrementFloat(\float $float) { return $float + 1; }

> More importantly, this would be inconsistent with our existing type hints like array and callable.
It would only be inconsistent if you don't think it through end but sure 
it's more work. I have no idea how much.

On calling a function in week mode one or more magic methods could be 
used to add auto cast behavior like:

public function __toInt();
public function __toFloat();
public function __toString(); // it will be called already
public function __toArray(); // Not part of this RFC
public function __toInstanceOf($name); // Will be called if no one of 
the other pass

>> 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.
> In an ideal world we would only have the short or long form, sure. But this isn’t an ideal world, and PHP doesn’t have compile-time validation of type hints. It would be too easy to write foo(integer $bar) and miss that it is broken if the function isn’t called.
Please let us make PHP more ideal ;)

Your argument is nonsense. As long as you never test your (unittest or 
manual) you can't be sure to work well. The same argument could pass for 
current type-hinting. If that argument is serious you have to eg. 
automatically fix type errors in class names.

Btw. IDEs already warn if you use something undeclared project wide.

> I don’t think having both int and integer is really a problem. It’s not going to cause confusion, they are obviously the same type. Coding style guides will mandate one or the other.
What about double and real?

> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>

Thanks

Marc