Actually, static properties are probably simpler than I thought ... I'm still not sure about them though ...
I'd like to hear what others thing about static properties having types ... Cheers Joe On Wed, Mar 30, 2016 at 4:16 AM, Joe Watkins <pthre...@pthreads.org> wrote: > 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. > > Instance properties, the engine has good control over their manipulation, > for static properties it doesn't, it's not impossible, but feels separate. > > > 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. > > > 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. > > > 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. > > > 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 ... > > 6) and 7) and 8) just sound like bugs ... will look at those ... > > 9) I always intended to leave that to you :) > > Cheers > Joe > > > On Tue, Mar 29, 2016 at 11:59 PM, Dmitry Stogov <dmi...@zend.com> 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 <dmi...@zend.com> >> Sent: Tuesday, March 29, 2016 19:24 >> To: Joe Watkins >> Cc: Phil Sturgeon; krak...@php.net; internals@lists.php.net >> 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 <pthre...@pthreads.org> >> Sent: Tuesday, March 29, 2016 19:18 >> To: Dmitry Stogov >> Cc: Phil Sturgeon; krak...@php.net; internals@lists.php.net >> 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 <dmi...@zend.com<mailto: >> dmi...@zend.com>> 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 <pjsturg...@gmail.com<mailto:pjsturg...@gmail.com>> >> Sent: Tuesday, March 29, 2016 18:32 >> To: Andrey Andreev >> Cc: internals@lists.php.net<mailto:internals@lists.php.net> >> 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 >> >> >
