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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
