Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92012
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.136 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.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>
 <CAL=_i_knwzrcXdx1k4ii8YKzrgaREBFcHYGC9ZV_J05ZWVWmzg@mail.gmail.com>
 <CAEZPtU5j8X35w-Vc6L=j_Lrbm1i-ukX_2k0awxgTR8D-us796A@mail.gmail.com>
 <CAL=_i_mfUy0nv3FWtYVgzpMVUNyA8zBpxuu13cZ-j0Nr1BOkPA@mail.gmail.com>
 <CAL=_i_=7A8iC81KXuDMCHA_q-3=nB97nE1KePDZF5eVcEbdzmA@mail.gmail.com>
 <56FB7096.9090602@zend.com>
 <CAL=_i_ngwL+h-Tz=fY09pdVbTXHp+trEieNA=LJ8yHv5RGJkuw@mail.gmail.com>
CC: Pierre Joye <pierre.php@gmail.com>, PHP internals
	<internals@lists.php.net>, Philip Sturgeon <pjsturgeon@gmail.com>,
	"krakjoe@php.net" <krakjoe@php.net>
Message-ID: <56FB8EFA.5020108@zend.com>
Date: Wed, 30 Mar 2016 11:31:54 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAL=_i_ngwL+h-Tz=fY09pdVbTXHp+trEieNA=LJ8yHv5RGJkuw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080809090906010504070807"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2016 08:32:08.2021 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1786
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: dmitry@zend.com (Dmitry Stogov)

--------------080809090906010504070807
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit



On 03/30/2016 10:50 AM, Joe Watkins wrote:
> Morning Dmitry,
>
>     > 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.
>
> We didn't really invent anything, you are comparing them to 
> parameters, but not return values ... strangely ...

Return types don't have default values :)

>
> Return values are not implicitly nullable, and a few people have been 
> designing RFC's to tackle this issue by introducing expicitly nullable 
> types, or union types.

I know. Missing the ability to mix objects with null is a big problem, 
but it's unrelated.

>
> This code:
>
> class Foo {
>
>     public function getBar() : int {
>         return $this->bar;
>     }
>
>     private $bar;
> }
>
> $foo = new Foo();
>
> var_dump($foo->getBar());
>
> Should provide the same guarantees that this code does:
>
> class Foo {
>     public int $bar;
> }
>
> $foo = new Foo();
>
> var_dump($foo->bar);
>
> In either case, an exception will be raised.
>
> Given the following code:
>
> <?php
> class Foo {
>
>     public function getBar() : int {
>         return $this->bar;
>     }
>
>     private $bar = null;
> }
>
> $foo = new Foo();
>
> $foo->getBar();
>
> We throw an exception, because null is not a valid int, and types are 
> not implicitly nullable, even if parameters, and untyped properties 
> are ...
>
> <?php
> class Foo {
>     public int $bar = null;
> }
>
> $foo = new Foo();
>
> var_dump($foo->bar);
>
> Again, we raise an error, but much earlier this time ( we should all 
> agree earlier is better).

class Foo {
   public $bar;
   function foo (int $bar = null) { // <-- this already works fine
     $this->bar = $bar;
   }
}

class Foo {
   public int $bar = null; // <- with your approach, this is prohibited
   function foo (int $bar = null) {
     $this->bar = $bar; // <-- this won't work
   }
}

>
> What we have done is apply existing rules in a way that makes sense, 
> the only thing we invented is the rule that null is never a valid value.

Both views may make sense.
>
> We invented that rule first to make return types and property types 
> consistent, and, because without it, the guarantee that you will 
> always get a variable of the correct type is gone, and your code is 
> filled with null checks.

Nobody require to use "nullable" types. It's just a feature that we 
already may use for parameters, and miss for return values yet.
>
> There is value in nullable types, but they must only be explicitly 
> nullable, in exactly the same way that return values should be, and we 
> simply don't have syntax to support that at the moment.

Why can't we reuse the existing explicit syntax for parameters?

>
> I hope this makes some of these decisions clearer ...

One more thought about implicit initialization values. (int(0) for int 
instead of IS_UNDEF).
I'm not sure if this RFC is going to be accepted yet, but lets think we 
will also implement type hinting for arrays.
e.g. "array<int,int> $a[40];"  would create a packed array of integers 
with 40 elements.
I would prefer to have all elements initialized by int(0) instead of 
IS_UNDEF.
In this case we won't have to use zvals (and Buckets) for elements at 
all, and will able to narrow this type to native C array "long a[40];"
This would safe 3/4 of memory required for array, and improve data locality.

Actually, this is exactly the same for properties.

Thanks. Dmitry.

>
> Cheers
> Joe
>
>
>
>
> On Wed, Mar 30, 2016 at 7:22 AM, Dmitry Stogov <dmitry@zend.com 
> <mailto:dmitry@zend.com>> wrote:
>
>
>
>     On 03/30/2016 08:13 AM, Joe Watkins wrote:
>
>         Morning Dmitry,
>
>              So, I quickly reviewed the RFC and patch.
>
>              Static properties, and mixed declarations, are now
>         explained in the RFC.
>
>     Thanks. I'm not agree with decisions, but RFC is more complete now.
>     It would be great to have "static" typed properties at the same
>     time, but this may be more difficult.
>     Mixed declarations decision looks wrong to me, but right to some
>     others. From implementation point of view, it's not a big problem
>     to change it.
>
>
>              I made a couple of changes to the fetch_obj_w stuff, I'd
>         be grateful if
>         you could review that ... I didn't think I had got all possible
>         combinations, should be bit better, and drier ...
>
>              The overflow related stuff, I'll fix and explain in the
>         RFC, but I'll
>         let you have a go at perf stuff, and other outstanding things
>         now ...
>
>              */me leaves patch alone*
>
>
>     OK. I'll try to do something today.
>
>     Thanks. Dmitry.
>
>
>
>         Cheers
>         Joe
>
>         On Wed, Mar 30, 2016 at 5:26 AM, Joe Watkins
>         <pthreads@pthreads.org <mailto:pthreads@pthreads.org>> wrote:
>
>             Morning Pieere, Dmitry, all ...
>
>             Actually it's not so simple ... for object properties we
>             have ASSIGN_OBJ
>             opcode, but we don't have a special opcode for static
>             properties, and
>             ASSIGN doesn't have any information about where the var
>             came from, and nor
>             should it have that information ...
>
>             I'm going to stick the original decision, static
>             properties don't belong
>             until typed variables are a thing ...
>
>             Cheers
>             Joe
>
>             On Wed, Mar 30, 2016 at 4:57 AM, Pierre Joye
>             <pierre.php@gmail.com <mailto:pierre.php@gmail.com>> wrote:
>
>                 On Mar 30, 2016 10:17 AM, "Joe Watkins"
>                 <pthreads@pthreads.org <mailto:pthreads@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.
>
>                 Internally different but from users perspective it is
>                 the same (a class
>                 property). It would be nice to support that at the
>                 same time to avoid
>                 confusion.
>
>
>
>


--------------080809090906010504070807--