On Sat, Sep 14, 2019 at 10:47 AM Mike Schinkel <m...@newclarity.net> wrote:
> > On Sep 13, 2019, at 3:18 AM, Rasmus Schultz <ras...@mindplay.dk <mailto:
> ras...@mindplay.dk>> wrote:
> >
> > Assuming the fields of this entity are required, you would probably
> prefer
> > to add a constructor - but then property initializers aren't really
> useful
> > anymore.
>
> I think this is a false dichotomy; I can see benefit to having
> initializers in addition to constructors, even for the same classes.
>
> However, Object Initializers might be best when paired with a new magic
> method which let us call __init(), and a required modifier for properties.
>
> Using your Customer example, the __init() would be automatically called
> after __construct():
>
> class Customer
> {
> private string $name = '';
> required protected ?string $email = null;
>
> public function __construct(string $name, ?string $email = null)
> {
> $this->name = $name;
> $this->email = $email;
> }
>
> public function __init()
> {
> $this->name = ucwords($this->name);
> $this->email = sanitize_email($this->email);
> }
> }
>
> With __init() a developer could separate capturing construct parameters
> from initializing required fields, but the required modifier would allow
> developers to indicate which properties should be required.
>
> And it might even make sense to throw an error if an object initializer
> does not have an __init() method. Requiring __init() would ensure that
> classes not designed to work with initializers would never be initialized
> without required fields set.
>
> When creating an object using object initialization I think it should just
> bypass and only call __init(). PHP could generate an error if any required
> fields are not set.
>
> $customer = new Customer{
> name => 'mike schinkel',
> email => 'm...@newclarity.net <mailto:m...@newclarity.net>'
> }
> echo $customer->name; // Prints "Mike Schinkel"
>
> Actually, a required modifier would not be required to implement object
> initializers (no pun intended) but it would enable IDEs, PHP and other
> tools validate whether or not a required fields has been set.
>
> As an aside, it would be interesting if there were a __validate() magic
> method although it might harm performance too much. OTOH, it should not
> harm performance unless you actually use it:
>
> public function __validate(string $field):bool
> {
> switch ($field) {
> case 'name':
> return !empty( $this->name ) && strlen($this->name) >= 3;
> case 'email':
> return validate_email($this->email);
> }
> return true;
> }
>
> > a desire to use this language feature will drive architecture. ... this
> will
> > provide the wrong kind of motivation to make what are, effectively,
> > architectural decisions.
>
> The reason I badly want object initializers is to empower architectures
> that currently are not possible in PHP. So I see this as a positive.
>
> I see architectures used in other languages that reduce tedium and enhance
> reusability that we cannot implement in PHP because of lack of an object
> initializer.
>
> But maybe I do not realize what you are seeing? Can you please elaborate
> on the architectures you fear will emerge, ideally with examples and
> reasons why they should be avoided?
>
>
> -Mike
>
>
Hey Mike,
lazy initialisation is already possible in userland: adding more magic to
the language for a use-case that is already implemented seems problematic
to me.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
