[VOTE] Alternative typehinting syntax for accessors

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

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

On Mon, Jan 21, 2013 at 7:54 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:

• 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

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