Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZxYwXKLp8ASkjiwXgzDtjKxJ8rYROCM-t=8sU5=efhg2w@mail.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>
	<CAPhkiZxYwXKLp8ASkjiwXgzDtjKxJ8rYROCM-t=8sU5=efhg2w@mail.gmail.com>
Date: Tue, 22 Mar 2016 23:22:07 +0200
Message-ID: <CAPhkiZwOJOkNu4N=h+wQRX4w8-KV=zg9x4khhLRLu199YcqZxw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c08ca7a417df9052ea9ce6e
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: narf@devilix.net (Andrey Andreev)

--94eb2c08ca7a417df9052ea9ce6e
Content-Type: text/plain; charset=UTF-8

Hi again,

Apparently I misunderstood the parts of the RFC that I was most concerned
about (isset() and what causes magic method calls).
Joe clarified most of it for me elsewhere and so now I'll be answering my
own questions here, in case that helps anybody else:

On Tue, Mar 22, 2016 at 9:26 PM, Andrey Andreev <narf@devilix.net> wrote:

> 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?
>

Apparently, after you call unset() on any kind of property, magic methods
will be called the next time you try to access it - seems quite strange to
me, but not this RFC's fault, so ...


> 3. Why does unset($this->bar) call $this->__get('bar') and not
> $this->__unset('bar'), like it happens for all properties currently?
>

It doesn't.
The comment on line 7 makes it look like that's the case but actually tries
to say what I just did above.


> 4. Furthermore, why is unset($this->bar) valid on initialized properties,
> but not on uninitialized ones?
>
>
It's valid in both cases, I've misread the error message line.


> 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?
>
>
I still disagree with this, but it seems like I'm by far in the minority.


> 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?
>
>
I've misread the error message line for this one too, which is good,
because I was most concerned about being able to do an isset() :)

Sorry for the noise.


> Cheers,
> Andrey.
>

--94eb2c08ca7a417df9052ea9ce6e--