Hi Phil, Phil Sturgeon wrote:
1. How scared are we that integers can be expanded to floats on runtime?
This is a vaguely-worded question, and I'm concerned not everyone reading it might have the same interpretation.
If by "expanded" we mean that you can assign to an int value to a float typed property, that's fine. We already allow that, even in strict mode, for parameter and return type declarations. It just gets converted to a float.
But if you mean that you can assign a float to an int typed property, and have it not be coerced to an int, and have this work even in strict mode, I am against that. This would mean allowing integer properties to overflow to float, which entails a loss of information. If the declaration is `public int $a;` then $a should only be allowed to contain an integer. Allowing it to also contain a float so that overflow can happen confuses me - surely avoiding overflow is one of strict typing's benefits?
2. This whole temporary nullability situation, where unset properties will error on attempted usage if not set. Should they instead error after the constructor has been called if they are still not holding a value?
While I'd prefer it if objects were properly initialised by their constructors, I understand that this would be inconvenient for some people, so my position here is a weak No.
3. Weak vs Strict. Right now this is entirely strict, with no declare() to change mode. Reasons for this vary, from various sources, but include "Not sure how to implement it" and "Well people should not be using properties as part of their public API". Help on 3 would be appreciated.
When I first wrote my Scalar Type Hints RFC and included the optional strict typing mechanism, I didn't want to allow weak typing for return types, because I felt it would violate the robustness principle. However, I ended up allowing it because I feared the inconsistency would make the RFC less likely to pass. I'm still not sure if weakly-typed return types were a good idea.
Arguments are an input, return values are an output, but a property is sort of both. So parameter types should follow whatever works for both parameter and return types, and that's one reason I lean towards always strict mode here.
That the programmer would be unsure of the types used for an object's internal state, and that PHP might silently mangle the data, is also something I find concerning.
But if we need to allow weak mode for the sake of the PHP way, so be it. Thanks! -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
