Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91706
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
Message-ID: <56E9AAF1.7070200@garfieldtech.com>
Date: Wed, 16 Mar 2016 13:50:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: larry@garfieldtech.com (Larry Garfield)

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