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. > 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. > 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. > 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)? 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. More importantly, this would be inconsistent with our existing type hints like array and callable. > 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. 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. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
