Hi Larry and Nicolas, On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield <la...@garfieldtech.com> wrote:
> > I'd like to propose something on the topic. > > I'm adding object literals to the mix because that's another feature of the > > language that we're missing a lot IMHO. > > Actually, there is one existing syntax for objects: (object) [...] > > [...] > > 2) What's its order of execution with the constructor? Vis, does the > constructor run after __create or before? Does __construct get any > parameters passed to it? That's the interesting question, though there's probably not any sensible answer that works for all use cases. However, if this kind of object casting (object literal notation) was limited to a certain (extendable) internal class (SPL Struct?), we could have just a final public function __construct(array $properties = []) that then delegates the validation to an abstract __validation() method. Would that at least be a useful alternative to constructor promotion? > In that syntax, you have to remember which one comes first. There's no > indication for the casual reader why > > public private $property; > > and > > private public $property; I'm wondering - are there any use cases where you would have private read and public write? If not, maybe this issue can be simplified by adding (f.ex.) "semiprivate" and "semiprotected" attribute keywords, the idea being that they give readonly access to the anything else. Though I think it would be great to have a nice, gracefully extensible attribute syntax, maybe it's not necessary to fight over that for this particular issue? > Either way, what matters is who is in charge of dealing with the issues > this might create. In both ways, what matters is that the original author > won't be bothered for things that are not its responsibility. "I broke your > app because you messed up with that private property on a class I > authored?" no my problem. About final, I usually prefer using the "@final" > annotation: it expressed exactly what I need to express as the author of > the code: "if you extend, you're on your own - but I'm not dictating what > you can/can't do either". > > I think this reasoning applies to my view on immutability :) :-) I can relate to that in general. Though for immutability, I'm not so sure anymore... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
