# [VOTE] Alternative typehinting syntax for accessors

- Thread: https://externals.io/message/65053
- Original archive: https://news-web.php.net/php.internals/65053
- Started by Nikita Popov on 2013-01-21T18:03:09+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #65053 — Nikita Popov — 2013-01-21T18:03:09+00:00

URL: https://externals.io/message/65053#65053

Hi internals!

I've opened the vote on the proposal for the alternative accessor
typehinting syntax:

https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax#voting

The vote is done under the assumption that the main accessors RFC will
pass. If it does not, then this proposal is no longer relevant.

You can find the mailinglist discussion for this RFC here:
http://markmail.org/message/kzha62nyp4pj24ct

Thanks,
Nikita

---

## #65055 — Gustavo Lopes — 2013-01-21T18:54:01+00:00

URL: https://externals.io/message/65053#65055 · In reply to: #65053

On Mon, 21 Jan 2013 19:03:09 +0100, Nikita Popov <nikita.ppv@gmail.com>  
wrote:

> I've opened the vote on the proposal for the alternative accessor
> typehinting syntax:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax#voting
>
> The vote is done under the assumption that the main accessors RFC will
> pass. If it does not, then this proposal is no longer relevant.
>

I've voted "No" due to concerns I mentioned in most part in IRC, but which  
I think should be here on the record. So my voting statement:

I'm voting against this proposal because I think the proposed syntax  
strongly suggests that the property is bound to a specific type. This has  
several problems:

* It's a promise that's not guaranteed. As long as the getter is allowed  
to reference the value of the variable can arbitrarily be changed to  
whatever type. It may also be possible to do the same with unserialization.
* The benefits are minimal. The only real benefit is cutting maybe two  
lines of code in an indisputably common scenario.
* The idea of bounding a variable to a type, even if it worked with no  
loop holes, should be examined with much more care than this. We have  
nothing analogous already. It's a misleading argument to say this is just  
a syntactic sugar (technically it is), because it carries a strong  
psychological implication by analogy with other languages like Java. And  
of course, it it had no loopholes, it would mean that we would have gone  
to great lengths to force the property to be of a certain type, and then  
we would not be able to claim it was just a syntactic sugar. So the  
feature is either broken or it's not just syntactic sugar.
* And yes, next we'll start discussing extending this to other variables.  
Yes, this is a slippery slope argument. Slippery slopes are a real  
phenomenon. People interested in this topic can read this reference [1].

[1] https://www.law.ucla.edu/volokh/slippery.pdf

-- 
Gustavo Lopes

---

## #65056 — Lester Caine — 2013-01-21T19:18:42+00:00

URL: https://externals.io/message/65053#65056 · In reply to: #65055

Gustavo Lopes wrote:
> * And yes, next we'll start discussing extending this to other variables. Yes,
> this is a slippery slope argument. Slippery slopes are a real phenomenon. People
> interested in this topic can read this reference [1].
I'm with you on that Gustavo - but I can't vote. I'm against Accessors as well 
so if it goes through then I'll definitely be stopping with PHP5.4 and ensuring 
that remains available for the rest of my active programming life ... something 
I wish I'd done now with 5.2!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #65057 — Anthony Ferrara — 2013-01-21T19:28:12+00:00

URL: https://externals.io/message/65053#65057 · In reply to: #65055

Gustavo

I've voted "No" due to concerns I mentioned in most part in IRC, but which
> I think should be here on the record. So my voting statement:
>
> I'm voting against this proposal because I think the proposed syntax
> strongly suggests that the property is bound to a specific type. This has
> several problems:
>
> * It's a promise that's not guaranteed. As long as the getter is allowed
> to reference the value of the variable can arbitrarily be changed to
> whatever type. It may also be possible to do the same with unserialization.
>

This is pretty easily solved by removing the ability to return a reference
from the getter when the shortcut syntax is used. In fact, remove the
ability to set the body of a getter at all (it would only allow you to
specify the visibility. If you need references, you can't use this syntax...


> * The benefits are minimal. The only real benefit is cutting maybe two
> lines of code in an indisputably common scenario.
>

Cutting two lines of code per instance. And considering that this is used
all the time, that can add up to some pretty significant (if not trivial)
boilerplate that's removed...


Anthony

---

## #65058 — Gustavo Lopes — 2013-01-21T19:46:12+00:00

URL: https://externals.io/message/65053#65058 · In reply to: #65057

On Mon, 21 Jan 2013 20:28:12 +0100, Anthony Ferrara <ircmaxell@gmail.com>  
wrote:

> Gustavo
>
> I've voted "No" due to concerns I mentioned in most part in IRC, but  
> which
> > […]
>
> This is pretty easily solved by removing the ability to return a  
> reference from the getter when the shortcut syntax is used. In fact,  
> remove the
> ability to set the body of a getter at all (it would only allow you to
> specify the visibility. If you need references, you can't use this  
> syntax...

So now we have a new non-obvious special case for when a specific syntax  
is used. So much for the equivalence argument. Allowing no getter body has  
its own problems btw (lazy instantiation is no longer possible for  
instance).

In any case, you leave unanswered other scenarios. Unserialization (and  
remember there are various unserialization implementations)? Bug in the  
setter (though I'm sure we could remove the ability to set the body as  
well)? Now what's your solution? PHP should start policing the type of the  
properties in all those scenarios? Maybe we should introduce Error  
exceptions for those runtime field type mismatches, like the JVM does.

> > […]
>
> Cutting two lines of code per instance. And considering that this is used
> all the time, that can add up to some pretty significant (if not trivial)
> boilerplate that's removed...
>

OK, so we disagree on the social value of removing, let's say 20 lines of  
boilerplate.

But you still left unanswered my other concerns about the fact this  
actually transmits the idea that PHP will enforce the type of a variable.  
You may think that's not an issue; even then, I think this is a very  
important change that merits more discussion. It's interesting that you  
claim we "need a vision", but actually we could be about to start  
introducing a fundamental change in the language in an incremental  
backdoor fashion.

-- 
Gustavo Lopes

---

## #65060 — Crypto Compress — 2013-01-21T22:54:43+00:00

URL: https://externals.io/message/65053#65060 · In reply to: #65053

Hello Nikita,

for me this "maybe-of-type"-typehinting is a small progression in the right
direction.

But "Default values and nullability" would break existing code as you need
to add a default null at "design-time" (BC break):

<?php
class C {
     public $a; // public string $a = null;
     public $b; // public string $b = null;
     public function __construct($a, $b) {
         $this->a = $a;
         $this->b = $b;
     }
}

// test only a
$c = new C("foo", null);
var_dump($c->a === "foo");

// test only b
$c = new C(null, "foo");
var_dump($c->b === "foo");
?>

http://3v4l.org/4oi9k

cryptocompress

---

## #65061 — Nikita Popov — 2013-01-21T22:59:52+00:00

URL: https://externals.io/message/65053#65061 · In reply to: #65060

On Mon, Jan 21, 2013 at 11:54 PM, Crypto Compress <
cryptocompress@googlemail.com> wrote:

> Hello Nikita,
>
> for me this "maybe-of-type"-typehinting is a small progression in the right
> direction.
>
> But "Default values and nullability" would break existing code as you need
> to add a default null at "design-time" (BC break):
>
> <?php
> class C {
>     public $a; // public string $a = null;
>     public $b; // public string $b = null;
>     public function __construct($a, $b) {
>         $this->a = $a;
>         $this->b = $b;
>     }
> }
>
> // test only a
> $c = new C("foo", null);
> var_dump($c->a === "foo");
>
> // test only b
> $c = new C(null, "foo");
> var_dump($c->b === "foo");
> ?>
>
> http://3v4l.org/4oi9k
>
> cryptocompress
>

Sorry if it wasn't clear: The nullability stuff only applies if a typehint
is used. If no typehint is used, then you can freely assign null,
regardless of whether or not you have the "= null" in the declaration (no
typehint = everything's valid). "public $foo;" will continue to behave
exactly the same way it did before :)

Nikita

---

## #65062 — Crypto Compress — 2013-01-21T23:35:45+00:00

URL: https://externals.io/message/65053#65062 · In reply to: #65061

Am 21.01.2013 23:59, schrieb Nikita Popov:
 > Sorry if it wasn't clear: The nullability stuff only applies if a 
typehint
 > is used. If no typehint is used, then you can freely assign null, 
regardless
 > of whether or not you have the "= null" in the declaration
 > (no typehint = everything's valid). "public $foo;" will continue to 
behave
 > exactly the same way it did before :)
 > Nikita

Nonetheless there is the same complication. I like to test 
"half-instantiated"
objects (maybe this is common/best practice?):

<?php
class C {
     public string $a;
     public string $b;
     public function __construct($a, $b) {
         $this->a = $a;
         $this->b = $b;
     }
}

// test only a
$c = new C("foo", null); // fail
var_dump($c->a === "foo");

// test only b
$c = new C(null, "foo"); // fail
var_dump($c->b === "foo");
?>

So if i want typehinting, i have to add "= null" without any real benefit as
for testing. Current behavior doesn't restrict `NULL` values. Why change this?
"method-like optional values"?

---

## #65065 — Nikita Popov — 2013-01-22T08:07:08+00:00

URL: https://externals.io/message/65053#65065 · In reply to: #65055

On Mon, Jan 21, 2013 at 7:54 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote:

> * It's a promise that's not guaranteed. As long as the getter is allowed
> to reference the value of the variable can arbitrarily be changed to
> whatever type. It may also be possible to do the same with unserialization.
>

Yes, that's a good point. One can't see this proposal as an introduction of
strict typing, that fully guarantees that the property has one type and one
type only. The typehints are there to help the programmer find mistakes. If
he assigns a wrong type, then he'll get an error. But yes, it will break
down if he actively tries to work against the system. If you start
modifying unserialization input and stuff like that, you will be able to
work around this. Just like you can also work around the method typehints
if you feel like it. I still find them useful.


> * The benefits are minimal. The only real benefit is cutting maybe two
> lines of code in an indisputably common scenario.
>

It's not just about the lines of code. It's about having a more readable
and more intuitive syntax. Am I the only one who thinks that "public $date
{ get; set(DateTime $date); }" looks pretty ugly/unclear compared to
"public DateTime $date;"?

Thanks,
Nikita

---

## #65066 — Lars Schultz — 2013-01-22T08:15:24+00:00

URL: https://externals.io/message/65053#65066 · In reply to: #65065

Am 22.01.2013 09:07, schrieb Nikita Popov:
> It's not just about the lines of code. It's about having a more readable
> and more intuitive syntax. Am I the only one who thinks that "public $date
> { get; set(DateTime $date); }" looks pretty ugly/unclear compared to
> "public DateTime $date;"?

FWIW: I agree;) If accessors get through, I'd rather have this alternate 
syntax. The other looks like a typo. I don't get to vote though...

---

## #65077 — Richard Quadling — 2013-01-22T11:56:41+00:00

URL: https://externals.io/message/65053#65077 · In reply to: #65066

> Am 22.01.2013 09:07, schrieb Nikita Popov:
>
> > […]
>
>
> FWIW: I agree;) If accessors get through, I'd rather have this alternate
> syntax. The other looks like a typo. I don't get to vote though...


I'm not an expert, so I may be getting the wrong end of the stick.

If you type hint the property, you cannot supply anything but that
type when you set it?

Where as, if you type hint the set parameter, you can supply that
type, and have the set method extract/perform whatever is required and
assign that result to the local property, which may be of a different
type. I would assume that the property has it's own docblock to
reflect the stored type.

Of course, I certainly see a bad case of confusion being presented
here if the stored type and the set type are different. And it would
seem that type hinting the property would solve this, but you know
developers will always want to get around blocks, is there any
sensible use case for having type hinted set() parameter as well as
type hinted property?

Richard.
-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY