- I'm moving this into its own mail thread because talking about 5 different topics under the same chain is ridiculous (has anyone suggested forums instead of email??)
So here comes my round of feedback on the current proposal.
But before getting to that: I have collected a bit of data how getter and setter are currently used in Symfony and ZF:
https://gist.github.com/3884203 Mainly so I get a better overview of the situation, but might be of interest for other people involved
in this discussion too.
So, my points on the proposal, in no particular order:
- Typehints
The last revision of the proposal added the ability to typehint the
set() accessor, so that's a good start. Still I would like to go a bit further on this point. My data says that about 20-30% of all setters are
typehinted and it is highly probable that if we had scalar typehints (as I'm sure we will have in the future) that number would be even
larger. In particular I would like to have an easy way to typehint if I don't want to override any additional behavior.
Currently that would require me to write something along the lines of
this:
protected $_date;
public $date {
get() { return $this->_date; }
set(DateTime $date) { $this->_date = $date; }
}
This is a rather lot of boilerplate code just to add a typehint. With automatic properties this might be reduced to this:
public $date {
get();
set(DateTime $date);
}
This is already a lot nicer, because I don't have to implement the same getting and setting pattern again and again, but I still find that it
doesn't do a particularly good job at conveying its intention.
Rather, what that code really wants to say is just this:
public DateTime $date;
I think that it would be very beneficial to support this syntax, because I think that a large part of the use of the accessor proposal will
just be type checking. But if we indeed want to syntax we should reconsider the get {} set { $value; } syntax again, because as I
understand it the new get() {} set($value) {} syntax was mainly introduced to deal with setter typehints. If we chose to allow typehints
before the property name, then that wouldn't be necessary anymore.
So the above would actually introduce an get/set accessor rather than a property, correct? If we were to abandon the long form ( set(DateTime $date) { ... } ) and go back to the original syntax, then the only way to "type hint" would be with no custom accessor logic, which I don't think makes sense. Jazzer also has said as much in a reply, so I think keeping the new syntax is required if we are going to support Typehints at all.
I can agree though that the even further abbreviated syntax -> get/set accessor would be nice, however many have already pointed out that these "equivalents" reduce clarity, especially for the less "up to speed" of the developers. If they were to encounter that, they may have to really do some digging to realize that it's a "super auto implemented" accessor.
I am not one to believe that is a reason not to support it, only that it may meet with a great amount of resistance.
-Clint
public DateTime $date;
This is real progress, even if under the hood all it does is wrap
functions and use function type-hints. This piece of code is SO much
shorter and cleaner. Will it be a bit confusing to new developers?
Maybe, but I don't care. It is not aimed at making the lives of new
developers easy; it's designed to make the lives of those who know
about it easy. In any case, this is such an enhancement that I don't
think it would take very long before there would be plenty of
tutorials out there to help the beginners anyway.
Hi!
public DateTime $date;
This is real progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply explained in 9000
discussions we had on this topic before.
functions and use function type-hints. This piece of code is SO much
shorter and cleaner. Will it be a bit confusing to new developers?
Maybe, but I don't care. It is not aimed at making the lives of new
I think you should care. PHP is a beginner's language, it always was its
core market. Adding more and more complicated features that benefit 0.1%
of developers in PHP is a new direction, and I'm not sure at all it is a
good direction for PHP to take.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2012/10/16 Stas Malyshev smalyshev@sugarcrm.com
public DateTime $date;
This is real progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply explained in 9000
discussions we had on this topic before.
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.
Doing the same for object properties (always optional) could be very useful.
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what "rock-solid modern tool" means, though PHP is
trivially a modern tool by being a tool and existing right now ;)
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.
It however gave a permission to people to try sneak in strong-typedness
through various backdoors arguing exactly that: "but we have strong
typing for parameters, why not for other things?" I think it is not the
right approach. Also, the fact is that other dynamic languages do not
have strong typing. It may be they just aren't smart enough to recognize
everybody needs it - or there may be a reason why it doesn't happen. I
think there is a reason, which again was outlined some 9000 times here
on the list.
Doing the same for object properties (always optional) could be very useful.
Not really, since PHP is not a compiled language and as such does not
have static type controls. Now not only every foo($bar) can blow up but
also every $foo->bar = $baz. Not very useful.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2012/10/16 Stas Malyshev smalyshev@sugarcrm.com
Also, the fact is that other dynamic languages do not
have strong typing. It may be they just aren't smart enough to recognize
everybody needs it - or there may be a reason why it doesn't happen. I
think there is a reasonDoing the same for object properties (always optional) could be very
useful.Not really, since PHP is not a compiled language and as such does not
have static type controls. Now not only every foo($bar) can blow up but
also every $foo->bar = $baz. Not very useful.
If the first could be useful, the second could be useful too. Or you are
saying that parameters type hinting was a bad idea?
You can argue using other languages' design choices, but it shouldn't drive
our own choices. Every methods and properties are public in Python; it
doesn't mean PHP is doing wrong (nor Python is doing wrong).
Last thing: I agree with Clint and you. If it was early checked, it would
be better. But the current type hinting is far better than nothing at all.
Yes, we can't "lint" it, but it was pretty useful a big number of times in
my company.
was outlined some 9000 times here on the list.
OK, sorry for the trouble.
Hi!
If the first could be useful, the second could be useful too. Or you are
saying that parameters type hinting was a bad idea?
Given how it is understood now - as a first step to make PHP a strongly
typed language - yes, I'm starting to think it was. If it was understood
as it was intended - as a small hack to catch obvious code failures -
then it'd be OK (not that great, but fine) idea, but given that more and
more people misunderstand it as declaration of intent for PHP to be
strongly typed language - I think maybe we would be better off not doing
that after all.
Last thing: I agree with Clint and you. If it was early checked, it
would be better. But the current type hinting is far better than nothing
at all. Yes, we can't "lint" it, but it was pretty useful a big number
No, it's not better. Having code that can randomly fail with one error
message is not better than having code that can randomly fail with
another error message. It is more or less the same. It can actually be
worse since it'd introduce more boliterplate checks in wrong places
(i.e., you'd have to check every variable for correct type before
assigning it to typed property) and does not provide any control over
how the situation when something is wrong is going to be handled.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Last thing: I agree with Clint and you. If it was early checked, it
would be better. But the current type hinting is far better than nothing
at all. Yes, we can't "lint" it, but it was pretty useful a big numberNo, it's not better. Having code that can randomly fail with one error
message is not better than having code that can randomly fail with
another error message. It is more or less the same.
It actually makes a very big difference just how exactly the code
fails. Whether it fails at the point where you assign an invalid value
to a property or whether it fails 50 frames down the line where that
property is then read and you don't really know where that value came
from.
The extreme example of just how much of a difference it can make is
C++ template metaprogramming. If you ever used a heavily templated
library in C++ you'll know the pain of looking at a 400 line long
template trace and trying to figure just where you went wrong. It's
obviously not that extreme in PHP, but it's always better to get a
directly relevant error message, rather than the error popping up
somewhere down the line (or if you're very unlucky not turning up at
all).
It can actually be
worse since it'd introduce more boliterplate checks in wrong places
(i.e., you'd have to check every variable for correct type before
assigning it to typed property)
I see this argument crop up with every typehint discussion and just
don't understand it at all. Why would you want to check the variable
type everywhere? You just assign it and if it doesn't work, then you
get an error. Just like it should be. I mean, do you seriously check
the type of every function argument because you fear the parameter
type hints that much? Doesn't make sense to me.
and does not provide any control over
how the situation when something is wrong is going to be handled.
That's not related to typehints really. PHP just does not have a
usable mechanism for recovering from error situations. You can
register an E_RECOVERABLE error handler and let the code continue, but
it's all very inconvenient. Also, I never had a situation where I
wanted to recover from a failed parameter type check. I don't see how
property type checks are different.
Hi!
I see this argument crop up with every typehint discussion and just
don't understand it at all. Why would you want to check the variable
type everywhere? You just assign it and if it doesn't work, then you
get an error. Just like it should be. I mean, do you seriously check
No, you don't get an error. You'd get an error in compiled language. In
dynamic language, your client gets an error when his site is launched
and instead of happy launch his users get white screens. To avoid that,
you'd need to add checks - or just ship it as is and hope your unit
tests were as good as you hoped they are (which they never are).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I see this argument crop up with every typehint discussion and just
don't understand it at all. Why would you want to check the variable
type everywhere? You just assign it and if it doesn't work, then you
get an error. Just like it should be. I mean, do you seriously checkNo, you don't get an error. You'd get an error in compiled language. In
dynamic language, your client gets an error when his site is launched
and instead of happy launch his users get white screens. To avoid that,
you'd need to add checks - or just ship it as is and hope your unit
tests were as good as you hoped they are (which they never are).
Still don't quite understand it. If the type check fails, there is a
high probability that either a) there will be an error lateron, so you
get the whitescreen anyways, just with worse debugging information or
b) something will work incorrectly in the following code, thus making
the application behave incorrectly (which is arguably worse than
giving a WSOD as that at least makes the issue obvious).
2012/10/17 Stas Malyshev smalyshev@sugarcrm.com
No, you don't get an error. You'd get an error in compiled language. In
dynamic language, your client gets an error when his site is launched
and instead of happy launch his users get white screens. To avoid that,
you'd need to add checks - or just ship it as is and hope your unit
tests were as good as you hoped they are (which they never are).
I don't understand why this situation would be better without type hinting.
I guess you think it's worst to code with the feeling of having a safety
net (that's the feeling given by type hinting to most people) ? (no joke
here, I just want to understand)
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.It however gave a permission to people to try sneak in strong-typedness
through various backdoors arguing exactly that: "but we have strong
typing for parameters, why not for other things?"
This is a non-argument. You're always talking about people sneaking in
stricter typing and more typehints, but you're making it sound like
some fundamentally bad thing. I didn't actually see you argue, not
once, why stricter type checks are a bad thing. Clearly the community
has interest in this (both in property type hints and in scalar type
hints and ...), at least from where I'm standing. There certainly are
arguments for both sides, but I'd ask you to bring those forward if
you disagree, rather than making useless statements like these (and
the ones in your previous mail). Or if you feel like you already
explained it too often, give us some links. You know that the mailing
list is not really searchable.
Also, the fact is that other dynamic languages do not
have strong typing. It may be they just aren't smart enough to recognize
everybody needs it - or there may be a reason why it doesn't happen.
I guess that you looked at Python and Ruby making those statements?
Well, those are just two languages, with a completely different object
model. PHP on the other hand has an object orientation system which is
much closer to Java and as such has different needs. Also, I should
point out that there are scripting languages that have optional
strict typing and recently there turn up more of those. One of the
newer languages is Dart and another that came very recently is
TypeScript. TypeScript is a JS superset (which compiles to JS), so
there you have a very dynamic language hands in hands with
(optional) strict typing. Actually JS is a good bit more dynamic than
PHP, for that matter. I hope you now see that this idea is not unique
to PHP and might not be as absurd as you are making it sound.
Not really, since PHP is not a compiled language and as such does not
have static type controls. Now not only every foo($bar) can blow up but
also every $foo->bar = $baz. Not very useful.
The code would blow up anyways (hopefully). The difference is where it
blows up. At the root of the problem or somewhere deeply down the
line.
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what "rock-solid modern tool" means, though PHP is
trivially a modern tool by being a tool and existing right now ;)
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.
It however gave a permission to people to try sneak in strong-typedness
through various backdoors arguing exactly that: "but we have strong
typing for parameters, why not for other things?" I think it is not the
right approach. Also, the fact is that other dynamic languages do not
have strong typing. It may be they just aren't smart enough to recognize
everybody needs it - or there may be a reason why it doesn't happen. I
think there is a reason, which again was outlined some 9000 times here
on the list.
Doing the same for object properties (always optional) could be very useful.
Not really, since PHP is not a compiled language and as such does not
have static type controls. Now not only every foo($bar) can blow up but
also every $foo->bar = $baz. Not very useful.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I would have to agree with Stas, the type hints that are presently implemented are failed code waiting to be found. Good luck if you're not monitoring your error logs. I can agree with the concept of wanting to avoid having to do all kinds of simple verification of input parameters but thankfully type hinting is optional.
I think if it had been done differently, at least when possible, such that errors occurring during compile time and thus could be -linted it would have been much more useful, re: the concept of fail early.
-Clint
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Tuesday, October 16, 2012 4:58 AM
To: Amaury Bouchard
Cc: Levi Morrison; Clint Priest; internals@lists.php.net; Nikita Popov (nikita.ppv@gmail.com)
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor SyntaxHi!
Not necessarily strongly typed. (sorry to land on this topic
afterwards) As I see PHP, it's a language that can be used as an
informal scripting language, but also as a rock-solid modern tool.I have no idea what "rock-solid modern tool" means, though PHP is trivially a modern tool by being a tool and existing right now ;)
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.It however gave a permission to people to try sneak in strong-typedness through various backdoors arguing exactly that: "but we
have strong typing for parameters, why not for other things?" I think it is not the right approach. Also, the fact is that other dynamic
languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a
reason why it doesn't happen. I think there is a reason, which again was outlined some 9000 times here on the list.Doing the same for object properties (always optional) could be very useful.
Not really, since PHP is not a compiled language and as such does not have static type controls. Now not only every foo($bar) can
blow up but also every $foo->bar = $baz. Not very useful.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2012/10/16 Stas Malyshev smalyshev@sugarcrm.com
public DateTime $date;
This is real progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply explained in 9000
discussions we had on this topic before.Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
Type hinting in parameters is a really good thing, and it doesn't
transformed PHP in a strongly typed language.
Doing the same for object properties (always optional) could be very useful.
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type, it is good to catch it as early as
possible. Extending this to also cover scalar coercable types would be
disastrous for the entire ecosystem and would completely change PHP. And
the fact that it is "optional" means absolutely nothing because once
some piece of your system has "optionally" decided to use it you don't
have the option not to abide by it, and it certainly isn't a hint, it is
a strong type. You will end up casting every call to everything all the
time just to be safe.
-Rasmus
2012/10/16 Rasmus Lerdorf rasmus@lerdorf.com
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type, it is good to catch it as early as
possible. Extending this to also cover scalar coercable types would be
disastrous for the entire ecosystem and would completely change PHP.
My point was not about scalar types. It was about porting the logic of
parameters type hinting to object properties. Nothing more, nothing less.
And the fact that it is "optional" means absolutely nothing because once
some piece of your system has "optionally" decided to use it you don't
have the option not to abide by it, and it certainly isn't a hint, it is
a strong type. You will end up casting every call to everything all the
time just to be safe.
I use parameters type hinting everyday. I can say it's very useful. And I
never needed to cast anything.
If the object model is used wisely, and if type hinting is used as an
option (i.e. don't use it when you know you'll need "mixed" data), it's a
very good thing.
I don't see why it couldn't be as good for properties as it is for
parameters. But Stas said it was already discussed a lot here, so I give
up. :-)
2012/10/16 Rasmus Lerdorf rasmus@lerdorf.com
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type, it is good to catch it as early as
possible. Extending this to also cover scalar coercable types would be
disastrous for the entire ecosystem and would completely change PHP.My point was not about scalar types. It was about porting the logic of
parameters type hinting to object properties. Nothing more, nothing less.And the fact that it is "optional" means absolutely nothing because once
some piece of your system has "optionally" decided to use it you don't
have the option not to abide by it, and it certainly isn't a hint, it is
a strong type. You will end up casting every call to everything all the
time just to be safe.I use parameters type hinting everyday. I can say it's very useful. And I
never needed to cast anything.
If the object model is used wisely, and if type hinting is used as an option
(i.e. don't use it when you know you'll need "mixed" data), it's a very good
thing.I don't see why it couldn't be as good for properties as it is for
parameters. But Stas said it was already discussed a lot here, so I give up.
:-)
It is foolish to think that these two bits of code are behaviorally different:
class Entity {
DateTime $last_modified;
}
//vs
class Entity {
public $last_modified {
get();
set(DateTime $last_modified);
}
}
The latter is a more verbose way of saying the former (assuming the
get returns the same type as the set accepts). The latter is
definitely capable of doing more than the former, such as private set
and public get. The former piece of code is simply a public get and
public set such that the type is always DateTime. It would be nice to
have the former syntax because of how succinct it is, but I am not an
experienced core programmer. I am unsure how feasible it is to
implement.
Hi!
It is foolish to think that these two bits of code are behaviorally different:
class Entity {
DateTime $last_modified;
}
The are different because this one looks like a strongly typed variable
which brings with it a lot of connotations which aren't immediately
obvious, and in fact most of this is not needed. 99% of use of parameter
typing I've seen is done for purely documentation purposes and that code
would break hard if these types do not match but in the code they never
do since there are no other types that end up there. I think having the
engine run a lot of extra code just for the sake of documentation is not
right.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
So the above would actually introduce an get/set accessor rather than a
property, correct?
Preferably it would a faster C based implementation for the check, but
in principle it could also use accessors to achieve the goal.
If we were to abandon the long form ( set(DateTime
$date) { ... } ) and go back to the original syntax, then the only way to
"type hint" would be with no custom accessor logic, which I don't think
makes sense.
Why? My point was that you could use that syntax with accessors too,
just like you can in C#:
public DateTime $date {
get { ... }
set { ... }
}
I don't know whether this is better or worse though. I like it because
it would be consistent between typehinted properties without accessors
and typehinted properties with accessors. But I can see how people
don't like the magic $value variable.
I can agree though that the even further abbreviated syntax -> get/set
accessor would be nice, however many have already pointed out that these
"equivalents" reduce clarity, especially for the less "up to speed" of the
developers. If they were to encounter that, they may have to really do some
digging to realize that it’s a "super auto implemented" accessor.
They don't really need to know that they are auto implemented
accessors (where would it make a difference?) Maybe they won't even be
accessors. It's just an implementation detail. From looking at it,
it's just a property with a type, just like you know it from C++, C#,
Java or whatever.
Nikita