Stas,
You really put it in the same answer as telling me it's the same as
> parameter defaults? Here you introduce completely new concept, not
> existing in PHP at all - non-constant initializers. And this is a whole
> new can of worms - when it should be run, what should happen when it's
> run, what is the order, etc. And we already have a perfectly good place
> to do this - constructors. We don't really need this whole new level of
> complications with dynamic initializers, just do it in the constructor.
I didn't introduce it. It was introduced in another thread about this very
same RFC.
As far as "introduce completely new concept, not existing in PHP at all",
that's the entire purpose of an RFC. That's what we're doing right here.
We're talking about introducing new functionality and features that may
make people's lives easier. So to discuss the feature, yet limit it to not
including new functionality, is rather odd...
> > As far as "why not just make it always allow null" is that it half
> > defeats the point of typed accessors in the first place. Java has huge
>
> Of course it does not. It would be really useless addition if the whole
> point of it was not allowing nulls in variables, and pointless too,
> since there's no way do to it. Even with initializers, how you guarantee
> that no code is run before your initializer? Like another initializer?
> You can not. So you always have a possibility of having null. It is true
> in any language, not just Java - pretty much any language that has
> object types also has "empty" value.
You always have the possibility of having null before the object is
constructed. That's given.
But after the constructor finishes, you can actually guarantee that the
property is never null. For example:
class Foo {
private $other;
final public function __construct() {
$this->other = new Other;
}
}
What case, other than reflection abuse, is $this->other *ever* null after
construction? The only case is when the class itself sets it to null. Which
is quite easy to check for when looking at the class.
Having an empty type, and having it be able to be set on anything are two
very different concepts. Take for example method type hinting:
function foo(Bar $bar) {}
In PHP, inside foo(), $bar will *never* be anything except an instance of
Bar. It's not possible. Trying to pass Null would generate a catchable
fatal: http://codepad.viper-7.com/Le3jC1
This concept is just an exception of that. After construction, if the
property is not declared with = NULL, it's never allowed to be set to it.
Simple as that. It's the same thing as setting the setter to a function
which type hints against Bar $bar instead of Bar $bar = NULL;
> > issues with 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
>
> And you will have to ensure constructor never accesses this property,
> constructor can never be extended with a code that uses this property,
> constructor never calls any outside method that may use this property,
> etc., etc. The complexity of this "solution" quickly gets out of hand
> and does not guarantee anything in fact. And now you also have to deal
> with unset() failing with a fatal error, too.
No language can protect you from yourself. If you do something inside the
class that screws everything up, then you're SOL. That's not what this
concept is about. It's about me as the class writer *knowing* that nobody
outside my class can screw it up. I know that if I write my code correctly,
that nobody can set it to null and screw me up.
As far as unset failing, we already have the ability to do that right now
with __unset(). All this is doing is applying it to the implicit
declaration when providing a type-hinted property variable...
> > explicitly Not allowing null. In fact, I'd argue that the "not allow
> > null" use-cases are the most frequent and most critical ones...
>
> If the whole point of this feature is to save is_null check, I do not
> think we need it in PHP, since it can not guarantee it, and it does much
> more and changes much more in the language than simple is_null check.
No. The whole point of this is to make defensive coding easier. We can do
it today with a combination of __get, __set, __unset. But that's dirty as
hell, and leads to LOTS of code doing the same thing over and over again.
Instead, we're looking at techniques that make peoples lives easier by
reducing the boilerplate that they need to write. Just like the generators
RFC... Generators don't provide anything that isn't already possible with
iterators. They just make the amount of boilerplate required a LOT lower.
And this concept does the same. And that doesn't even make mention of the
performance gains by having the getter/setter be written in C instead of
PHP...
Anthony
