Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91865
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56F16023.1010002@gmail.com>
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
	<1458149992.3969.2.camel@kuechenschabe>
	<BLU436-SMTP1394648F9BABA2FA74BFC4DE28A0@phx.gbl>
	<1458151531.3969.8.camel@kuechenschabe>
	<BLU436-SMTP2092DD6AFBC93D83397A3C7E28A0@phx.gbl>
	<1458153695.3969.16.camel@kuechenschabe>
	<3F.70.02405.6803BE65@pb1.pair.com>
	<56F01545.8080008@gmail.com>
	<CAF+90c-Z82kBT18ivvKejD5_dBf=dtbNYN-cZcyO1K=0C1WcLA@mail.gmail.com>
	<56F14572.701@gmail.com>
	<56F15EF5.80006@telia.com>
	<56F16023.1010002@gmail.com>
Date: Tue, 22 Mar 2016 21:26:39 +0200
Message-ID: <CAPhkiZxYwXKLp8ASkjiwXgzDtjKxJ8rYROCM-t=8sU5=efhg2w@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0470ae4ba0fb052ea83173
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: narf@devilix.net (Andrey Andreev)

--94eb2c0470ae4ba0fb052ea83173
Content-Type: text/plain; charset=UTF-8

Hi,
This mail turned out to look quite a lot like a rant - sorry about that. I
can assure you I am genuinely looking for answers on the questions that
follow ...

https://3v4l.org/Lq5dA/rfc#tabs (an example is from the RFC itself)

It doesn't make sense to me, for numerous reasons:

1. Why are any magic methods called for public (and already declared)
properties, especially from inside the object's constructor?
2. Even if there's a sane reason for that first point, a __get() call may
not even attempt to access the property in question, so why is its return
value taken into account?
3. Why does unset($this->bar) call $this->__get('bar') and not
$this->__unset('bar'), like it happens for all properties currently?
4. Furthermore, why is unset($this->bar) valid on initialized properties,
but not on uninitialized ones?

I also still feel that completely preventing a typed property to "return
NULL" in any shape or form is a way too opinionated decision ...

I can understand disabling explicit NULL assignments. And I don't
particularly like it, I also understand throwing TypeError for direct
access on an unitialized property:

    class Foo {

        public int $bar;

    }

    $foo = new Foo();

    $this->bar = null;
    if ($this->bar === null) {}

    // ^ I agree, both of these SHOULD throw TypeError

However, I see no reason why this shouldn't work:

    class Foo {

        public int $bar = null;
    }

    $foo = new Foo();
    is_null($foo->bar) && doSomething();

That's no longer a question of should uninitialized properties be
accessible; it's explicit - the developer writing this *wants* the property
to have NULL at least as the default value.
With all the "consistency" arguments thrown against virtually all proposals
so far, why is this one inconsistent with typed parameters?
Sure, the RFC half-addresses this question by saying that it intentionally
doesn't touch on the subject of nullability because of the eventual union
types feature, but that feature is not even officially proposed yet.
Theoretically, it may not ever change its status from "Draft", let alone be
accepted, but even if so - I don't see it disallowing function foo(int $bar
= null) {}, so does it apply here?

And finally, and most importantly - throwing a TypeError even on an isset()
... that's not even a function call.
Some may prefer to think of isset() as if it was an inverted is_null(), but
we all know it's not quite the same and it doesn't emit notices for
undefined variables. So why should it throw TypeError for properties? Why
can't we at least have a way to *check* if a property was ever initialized?

Cheers,
Andrey.

--94eb2c0470ae4ba0fb052ea83173--