Hi!
> Wait, what are you talking about here? About this particular proposal or
> the accessors RFC in general? The fact that unset() can throw a
> (catchable) fatal error is just the same without this particular syntax.
This is pretty bad by itself. But the fact that everybody would be using
this feature in this way - since they would think "I don't need null
default, null is always the default and I'd initialize it in the ctor
anyway", not realizing that declaring "public DateTime $foo" blocks
unset - is even worse. At least with setter you need to explicitly
define typehinted setter - and there you have a place to think about it.
With "public DateTime $foo" 99% of people would never even remember to
think about it - until they'd start getting mysterious fatal errors on
unsets. That's why I think it makes it worse.
> 1. First of all, there never is a guarantee for everything. All kinds of
This is a useless platitude. I've outlines specific scenarios where it
fails to do what it seemingly promises to do.
> 2. Secondly, the main purpose of typehints is to prevent people setting
> incorrect values. If you know that only a "DateTime" instance is valid
> and that NULL is not valid, then you should allow only that, only the
> DateTime. Allowing NULL absolutely doesn't make sense (as it's not a
Allowing NULL is *inevitable*, that's the whole point, since that's what
the value is when the object is created, and you can not guarantee this
value was initialized. The only thing you can do is to *pretend* it can
not be null, even though you know it can be, and ignore the cases where
it is null, because you're sure your code is correct.
> Your argumentation goes along the lines of "It's possible that this
> property could maybe end up being NULL, so it does not make sense to
> prevent people from assigning NULL". The second part of that sentence
You can easily prevent people from assigning NULL, what you can not do
is guarantee the property never returns NULL (at least not with the
short syntax, the explicit accessor is a different thing, there you can
do it just fine). That's what is wrong with this thing. This shortcut
doesn't actually do what people would think it does. It is misleading.
> 3. The constructor is typically (or at least that's how it *should be*)
> small and doesn't do work, so there isn't much to do wrong. But sure, it
"Small" and "work" have wildly different definitions. In real life,
constructors frequently call out to other methods when initializing.
E.g. somehing like:
public function __construct() { $this->log = Logger::getInstance();
$this->db = DBFactory::getInstance(); }
or something like that, happens all the time. Now imagine Logger somehow
tries to use something that uses $this->db and assumes it's not null -
since it can never be null, we declared it not null!
> I'd summarize this as follows: The typehint prevents all
> incorrectly-typed assignments, but it does not prevent missing
> initialization. Your argumentation is that because it can't prevent
> missing initialization, we shouldn't bother with preventing incorrect
> assignments either. I hope you realize that this makes no sense.
It's not my argument. My argument is this syntax makes promise of the
value never be null and it is specifically proposed with this sole
purpose (and argument is unless it is the promise this syntax has no
value at all). And it does not do that. In addition, it breaks unset()
which would be completely unexpected by 99% of users. I think in this
way it will do more harm than good as it would lead people to write code
which behaves worse than if this syntax did not exist.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
