Hi Sara,
> De : [email protected] [mailto:[email protected]] De la part de Sara
> Golemon
>
> So, if you'll permit me to summarize your message. The following
> would be palatable to you?
>
> * Lossless coercion. This would sit somewhere between strict types
> and weak types as lossy conversions (object->__toString() for objects
> passed where string expected, any->bool) would be disallowed, but
> lossless conversions (numeric strings to number types, int to float,
> whole floats to ints, numbers to strings -- But no implicit
> conversions to bools, no non-numeric strings to numerics, etc...)
1. it must be implemented as a modification to zpp conversion rules. IMHO, a
third mode would be the worst thing to do.
2. It is not not about being lossless or not. People expect bool -> int to be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which don't
make sense, and disabling them. Examples include bool conversion to any other
type and, of course, disabling trailing chars in numeric strings.
4. Once this is done, 99% of strict type proponents already said they would be
OK with the so-called (not so) weak mode, making it possible to get rid of this
far from perfect two-mode mechanism (actually, this two-mode approach more and
more reminds me a great idea about bringing transparent Unicode support in PHP).
If future development tools require more precise types (and they probably
will), the mechanism can be extended with new keywords, but the idea is never
using the same keyword for different ways to check a zval. New keywords would
be defined at the zpp level, keeping internal and userspace features in sync.
Would you agree proposing this as an option in 0.4 ? Actually, I will write it
as a separate RFC as modifying zpp conversion rules has impacts well beyond
type hinting. Then, type hinting RFCs can reference it.
> * Exclude internal functions from the strict switch. (Perhaps have a
> separate switch for internal functions at a later date)
This would make the feature inconsistent from an end user's pov.
If a user enables strict mode, he assumes strict checks for every function he
calls. *We* know that userspace and internal functions use different
mechanisms, but the end user doesn't have to know. From his pov, a function is
a function. If the documentation states that the function he's calling in
strict mode accepts int, he will expect int to be checked in strict mode. We
cannot say 'Oh, wait, it's an internal function, the rules are not the same'.
The distinction between internal and userpace functions is irrelevant for him
and has to remain so.
So, from all these arguments, I now think that strict types, as defined in 0.3,
are not the best solution.
> With option to introduce features such as the following at a later date:
>
> * Union types (e.g. function foo((int | float) $value): (bool | string) { ...
> })
> * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
> standard (like numeric), others user-definable)
As I told Zeev, union types can be kept for the future if we don't go the
nullable road, as it would be too confusing making 'string|null' and '?string'
synonyms.
The question of null is not so simple. IMO, it should be left for a future
discussion about union types. Anyway, once people get used to scalar hinting,
the need for union types will arise quickly.
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
