On 3/16/16 11:36 AM, Phil Sturgeon wrote:
Hello everyone,
I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.
https://wiki.php.net/rfc/typed-properties
Overall thought: <3
I would really appreciate constructive feedback on this RFC, with a
few areas especially:
1. How scared are we that integers can be expanded to floats on runtime?
As others have said, follow the existing widening rules. int->float is
safe for strict params and returns, so should be safe here for the same
reason. Inconsistency here would suck.
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?
I fall back to a statement I made in a blog post a while back:
http://www.garfieldtech.com/blog/empty-return-values
" But consider what you could do instead that would not force me to
throw is_null() around my code, because throwing is_null() around my
code makes me sad. NULL should be the return value of last resort,
because it means nothing. (Literally.)"
Allowing default-null on properties means that as someone using that
property, I have two options:
1) Throw a lot of is_null() calls around my code.
2) Assume that whoever initialized the code provided a value by the time
initialization is done and skip those extra checks.
Insert that old adage about what happens when you assume.
End-of-constructor checks seem like a good approach; they have to be
uninitialized at some point when new is called initially, but they
should be guaranteed set as soon as possible. End of the constructor is
"as soon as possible", and I think reasonably
static-analysis-catchable. (Meaning my IDE can yell at me appropriately.)
That removes is_null() calls from the rest of my codebase, which is a
good thing.
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".
I cannot help on the implementation front, but logically it doesn't make
sense to me as an end-user that properties are always-strict while
params and returns are not. As with integer->float widening,
consistency should be the default position. If that means a slight
performance hit in weak mode (does it?), well, that's one more reason
people should be using strict mode. :-)
Regarding the void type (as noted in the Open Issues section): A void
type on a property renders that property useless. You couldn't ever
assign to it, and it would only ever evaluate to NULL at best. So... do
whatever is easiest, implementation-wise. If it's technically possible
to define a property as void, meh, I don't much care since it's useless
anyway. If it's easy enough to forbid, forbid. If it's easier to make
it legal syntax but optimize out of the class structure on compile,
that's good too.
Syntactically, what happens if you omit the visibility keyword, or use
var? (Assuming var survives.) Ie, is this legal:
class Foo {
int $a;
}
And/or, since most other pre-keywords are of flexible position would
this be legal:
class Foo {
int public $a;
}
Like Adam, I'd also be interested in the implications for the property
getter/setter RFC as I would love for that to come back at some point.
(Out of scope for this RFC, certainly, but making sure it won't break
anything in that direction later would be good.)
--
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
