Re: [RFC Discussion] Typed Properties

On Wed, Mar 16, 2016 at 1:08 PM, Adam Harvey <aharvey@php.net> wrote: > On 16 March 2016 at 09:36, Phil Sturgeon <pjsturgeon@gmail.com> wrote: >> 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". > > As much as I didn't (and don't) particularly like the declare() > switch, it doesn't seem like a good idea to me to introduce a typing > feature a year after it that doesn't use it, but has its own mode of > operation. To me, it seems like this: > > class Foo { > public int $num; > } > > (new Foo)->num = $bar; > > Should behave the same as the setter equivalent does today: > > class Foo { > public $num; > public function setNum(int $num) { $this->num = $num; } > } > > (new Foo)->setNum($num); > > That is: if $num either can't be coerced to an integer (in weak mode) > or isn't itself an integer (in strict mode), a TypeError should be > thrown. > > We could argue about whether properties should be part of a public > API, but the reality is that a class declaring a public property > effectively is making it part of its API, whether you or I think it's > a good idea or not. :) > >> We'll have a nice, orderly, constructive conversation about this RFC, >> and improve the patch as you all provide feedback. >> Let me know what you think folks! > > The above leads into another question I'm interested in your (and > Joe's) general thoughts on: how do you think this would potentially > intersect with a property getter/setter RFC in the future? Might be > good fodder for the future scope section! Yeah, I'll add a note about that. :) > Finally, while the RFC shows invalid assignments generating fatal > errors, the patch seems like it throws TypeError exceptions instead. > Which one is the desired behaviour? (I'd prefer TypeError, personally, > for consistency with function type declarations today.) > > Adam If you put them in the class definition you'll get a fatal error from the compiler (might change) and at runtime you get an Error. Different things for different things. :)