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
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
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, 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
whichI 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...
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.
- 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...
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
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
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...
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...
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
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");
?>
cryptocompress
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");
?>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
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"?