On 1/5/13 7:25 PM, Anthony Ferrara wrote:
No, the other initializer that would be useful is `new Foo`. Assigning a
default value is not an initializer. An initializer is something that's run
on object construction (and has been discussed in other threads):
class Foo {
public DateTime $bar {
init: { $bar = new DateTime(); }
}
}
I think property init() would enable two bad practices:
1. putting too much logic in a property (SRP)
2. building dependencies within the object instead of injecting them (the better way is
what we already do: receive dependencies in the constructor and assign them to the properties)
null pointers. And if you set the property in the constructor (and it's
typed), you should never have the chance for it to be non-null, unless you
explicitly define it that way. Otherwise, you'd have to litter your code
with is_null checks... Which defeats the point of the syntax in the first
Which is why I think the default setting signature should not have "= null". If someone
wants to allow setting the property *back* to null, they could easily:
public Foo $foo {
get;
set($value = null);
}
I agree with you that, in an ideal world, a property with a declared type would *never not
have* that type, but I think a property init() would be a bad tradeoff to make that a reality.
The class constructor is the best place to do this, and maybe this is why C# forces
property storage to be in fields; you can set fields directly from the constructor without
going through property setters.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
