Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CY1PR0201MB17867DAC10D401EE9EC49CBCBF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<1458149992.3969.2.camel@kuechenschabe>
	<BLU436-SMTP1394648F9BABA2FA74BFC4DE28A0@phx.gbl>
	<1458151531.3969.8.camel@kuechenschabe>
	<BLU436-SMTP2092DD6AFBC93D83397A3C7E28A0@phx.gbl>
	<1458153695.3969.16.camel@kuechenschabe>
	<3F.70.02405.6803BE65@pb1.pair.com>
	<56F01545.8080008@gmail.com>
	<CAF+90c-Z82kBT18ivvKejD5_dBf=dtbNYN-cZcyO1K=0C1WcLA@mail.gmail.com>
	<56F14572.701@gmail.com>
	<56F15EF5.80006@telia.com>
	<56F16023.1010002@gmail.com>
	<CAPhkiZxYwXKLp8ASkjiwXgzDtjKxJ8rYROCM-t=8sU5=efhg2w@mail.gmail.com>
	<CAPhkiZwOJOkNu4N=h+wQRX4w8-KV=zg9x4khhLRLu199YcqZxw@mail.gmail.com>
	<CABDNdAGh4OjkkEQim6oYK=sZ=zj1Q==HzE=SLJ1E8=a=ku1DqA@mail.gmail.com>
	<CY1PR0201MB17863E4B9D9F53151A900DCDBF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
	<CAL=_i_mNwmpg0PWmrm3nTZxn6s33u2QUzavk8w0Fk1OGvbWJtA@mail.gmail.com>
	<CY1PR0201MB1786AAFDC6170AB1585CA7F5BF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
	<CY1PR0201MB17867DAC10D401EE9EC49CBCBF870@CY1PR0201MB1786.namprd02.prod.outlook.com>
Date: Wed, 30 Mar 2016 04:16:49 +0100
Message-ID: <CAL=_i_knwzrcXdx1k4ii8YKzrgaREBFcHYGC9ZV_J05ZWVWmzg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Phil Sturgeon <pjsturgeon@gmail.com>, "krakjoe@php.net" <krakjoe@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1143312c993457052f3b931d
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: pthreads@pthreads.org (Joe Watkins)

--001a1143312c993457052f3b931d
Content-Type: text/plain; charset=UTF-8

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 <dmitry@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 <dmitry@zend.com>
> Sent: Tuesday, March 29, 2016 19:24
> To: Joe Watkins
> Cc: Phil Sturgeon; krakjoe@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 <pthreads@pthreads.org>
> Sent: Tuesday, March 29, 2016 19:18
> To: Dmitry Stogov
> Cc: Phil Sturgeon; krakjoe@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 <dmitry@zend.com<mailto:
> dmitry@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 <pjsturgeon@gmail.com<mailto:pjsturgeon@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
>
>

--001a1143312c993457052f3b931d--