Morning Dmitry,
1) static typed properties are prohibited. why?
Feels like that's a separate feature, static properties are as good as makes no difference, global variables.
From the user perspective there is not a lot of difference between regular and static properties.
Instance properties, the engine has good control over their manipulation, for static properties it doesn't, it's not impossible, but feels separate.
so this is an implementation problem.
2) The handling of multiple properties in the same declaration statement is inconsistent.
This feels consistent to me .. in other languages where the type is required, it makes sense to assume the type is implied.
In a language where the type is optional, public int $foo, $bar; feels ambiguous to me.
But this is the valid syntax for others. And this is going to be yet another reason to blame PHP.
3) We already have nullable arguments without any special syntax. We should reuse the similar approach for properties.
Making properties implicitly nullable defeats the object of trying to provide type safety.
Null is never a valid value for a typed property, if it were, you would never be sure of the type of variable you are getting, and would have to litter your code with is_null checks.
If we use one rule for arguments, why should we invent others. Properties are going to be nullable only if you explicitly initialise them with NULL.
I think it might be better to implicitly initialize them according to type (if default value is not provided): bool by false, int by 0, double by 0.0, string by "" (interned), array by [] (immutable), objects by NULL (always nullable).
Definitely not, lying about the default value isn't a good idea.
There are times when 0 is as valid as 1, or any other value for an int.
If you have declared that you know the type of the property, and you write code that accesses that property before there is any possible chance you have set the property, that's a programming error.
We should not hide that error with a default value, or by allowing the engine to return null.
Your arguments may make sense, but PHP never required property initialization. Introducing orthogonal rules for typed properties seems strange.
We can't change property_info->type_ce for internal properties, because they are shared between threads.
I'm not sure what to do about that ... will think ...
may be it's possible to make a special pass at the end of MINIT to initialize all property_info->type_ce, for all internal classes.
6) and 7) and 8) just sound like bugs ... will look at those ...
9) I always intended to leave that to you :)
I'll spend some time trying to find a good solution.
Thanks. Dmitry.
Cheers
Joe
On Tue, Mar 29, 2016 at 11:59 PM, Dmitry Stogov <
[email protected] <
mailto:[email protected]>> wrote:
Hi,
Reviewing the patch sources I found few inconsistent decisions not
mentioned in RFC.
1) static typed properties are prohibited. why?
2) The handling of multiple properties in the same declaration
statement is inconsistent.
public int $bar, string $qux; // this works
public int $bar, $qux; //this emits error: Untyped
property A::$qux must not be mixed with typed properties
It's better to allow type only before first property in the list
and apply them to all of them (like C, Java and others).
Is this just an implementation issue?
3) We already have nullable arguments without any special syntax.
We should reuse the similar approach for properties.
public int $num = null;
4) There's a mess with initialization of typed properties. (typed
properties are initialized by IS_UNDEF, untyped by IS_NULL).
I think it might be better to implicitly initialize them according
to type (if default value is not provided): bool by false, int by
0, double by 0.0, string by "" (interned), array by []
(immutable), objects by NULL (always nullable).
Also I found a number of implementation problems:
5) We can't change property_info->type_ce for internal properties,
because they are shared between threads.
Can property of Internal class have a type of user class? This
would lead to crash on second request.
6) $x->a++; doesn't throw on overflow
7) ++$a->a; and += throw on overflow, but change the property
value to "float"
8) Reference handling in ZEND_FETCH_OBJ_W is not robust. At least,
EXT_NOP or TICK may be inserted before next ASSIGN_REF. Handling
of ZEND_ADD_ARRAY_ELEMENT and ZEND_YIELD is too pessimistic,
missing support for SEND_REF and may be others.
9) Often calls to zend_object_fetch_property_type_info() are not
good for performance. Currently FETCH_OBJ_X cache "offset" to
property, in general we may go back and cache address of
"property_info", but this is going to decrease performance for
each property access. It would be great to find a better solution.
May be using zval.reserved.
I assume, I didn't find all problems yet.
I think, both RFC and implementation have problems.
I may try to help with implementation.
(9) is the most difficult problem, and I'll try to solve it first.
Do you see any problems with updating RFC with (2), (3), (4)?
(1) would also make proposal more consistent, but I assume you got
some troubles implementing it and I don't know about them yet.
Thanks. Dmitry.
________________________________________
From: Dmitry Stogov <[email protected] <mailto:[email protected]>>
Sent: Tuesday, March 29, 2016 19:24
To: Joe Watkins
Cc: Phil Sturgeon; [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
Thanks. I'll start tomorrow morning and will try to send you
update by the evening,
________________________________
From: Joe Watkins <[email protected]
<mailto:[email protected]>>
Sent: Tuesday, March 29, 2016 19:18
To: Dmitry Stogov
Cc: Phil Sturgeon; [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
Hi Dmitry,
The patch is pretty close to complete.
When you start to dig a bit further, you'll notice that I
prepared for using cached pointers to prop info, but, I'm not sure
how to allocate those as the handlers are using the currently
allocated slots so differently.
I also patched opcache, but it's probably wrong (or not good
enough, not sure what to do about type_ce).
Please do start working on the patch, that would be great ...
I'll leave it alone for you to do your thing :)
Cheers
Joe
On Tue, Mar 29, 2016 at 5:12 PM, Dmitry Stogov <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> wrote:
Hi Phil, hi Joe,
Is your patch complete?
I took just a brief review yet, and I would like to make a deep
check once again (and may be optimization).
I saw, the patch makes some slowdown, but less than I expected.
If you are not going to modify the patch in next two days, I would
start working on it tomorrow.
RFC itself looks fine.
Thanks. Dmitry.
________________________________________
From: Phil Sturgeon <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>
Sent: Tuesday, March 29, 2016 18:32
To: Andrey Andreev
Cc: [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
I'd like to thank everyone for their feedback on this RFC!
It looks like the majority of concerns were solved during the course
of this discussion, which is great news.
The RFC has been expanded in a few areas to take care of a few other
concerns, so please go and review it and let me know if you have any
feedback.
https://wiki.php.net/rfc/typed-properties
Voting will start in a few days.
Cheers,
Phil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php