# [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax - Thread: https://externals.io/message/63408 - Original archive: https://news-web.php.net/php.internals/63408 - Started by Clint Priest on 2012-10-15T12:11:33+00:00 - Messages: 19 - 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 --- ## #63408 — Clint Priest — 2012-10-15T12:11:33+00:00 URL: https://externals.io/message/63408#63408 * 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: > > 1. 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 --- ## #63414 — Levi Morrison — 2012-10-15T14:12:21+00:00 URL: https://externals.io/message/63408#63414 · In reply to: #63408 > 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. --- ## #63433 — Stas Malyshev — 2012-10-16T07:56:42+00:00 URL: https://externals.io/message/63408#63433 · In reply to: #63414 Hi! > > […] > > 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 --- ## #63442 — Amaury Bouchard — 2012-10-16T09:51:07+00:00 URL: https://externals.io/message/63408#63442 · In reply to: #63433 2012/10/16 Stas Malyshev > > […] > > 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. --- ## #63443 — Stas Malyshev — 2012-10-16T09:58:11+00:00 URL: https://externals.io/message/63408#63443 · In reply to: #63442 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 --- ## #63444 — Stas Malyshev — 2012-10-16T09:58:18+00:00 URL: https://externals.io/message/63408#63444 · In reply to: #63442 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 --- ## #63449 — Clint Priest — 2012-10-16T10:37:34+00:00 URL: https://externals.io/message/63408#63449 · In reply to: #63444 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 Syntax > > Hi! > > > […] > > 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 ;) > > > […] > > 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. > > > […] > > 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 --- ## #63451 — Amaury Bouchard — 2012-10-16T10:44:15+00:00 URL: https://externals.io/message/63408#63451 · In reply to: #63443 2012/10/16 Stas Malyshev > 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 > > > […] > 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. --- ## #63454 — Stas Malyshev — 2012-10-16T10:55:37+00:00 URL: https://externals.io/message/63408#63454 · In reply to: #63451 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 --- ## #63471 — Rasmus Lerdorf — 2012-10-16T15:41:18+00:00 URL: https://externals.io/message/63408#63471 · In reply to: #63442 > 2012/10/16 Stas Malyshev > > > […] > > > 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 --- ## #63473 — Amaury Bouchard — 2012-10-16T16:31:49+00:00 URL: https://externals.io/message/63408#63473 · In reply to: #63471 2012/10/16 Rasmus Lerdorf > 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. :-) --- ## #63474 — Levi Morrison — 2012-10-16T17:17:52+00:00 URL: https://externals.io/message/63408#63474 · In reply to: #63473 > 2012/10/16 Rasmus Lerdorf > > […] > > > My point was not about scalar types. It was about porting the logic of > parameters type hinting to object properties. Nothing more, nothing less. > > > > […] > > > 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. --- ## #63492 — Stas Malyshev — 2012-10-17T10:22:53+00:00 URL: https://externals.io/message/63408#63492 · In reply to: #63474 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 --- ## #63494 — Nikita Popov — 2012-10-17T10:34:27+00:00 URL: https://externals.io/message/63408#63494 · In reply to: #63408 > 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 --- ## #63493 — Nikita Popov — 2012-10-17T10:51:21+00:00 URL: https://externals.io/message/63408#63493 · In reply to: #63443 > > […] > > 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. --- ## #63495 — Nikita Popov — 2012-10-17T11:04:04+00:00 URL: https://externals.io/message/63408#63495 · In reply to: #63454 > > […] > > 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 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. --- ## #63496 — Stas Malyshev — 2012-10-17T11:07:58+00:00 URL: https://externals.io/message/63408#63496 · In reply to: #63495 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 --- ## #63499 — Nikita Popov — 2012-10-17T11:17:32+00:00 URL: https://externals.io/message/63408#63499 · In reply to: #63496 > > […] > > 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). 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). --- ## #63505 — Amaury Bouchard — 2012-10-17T12:26:43+00:00 URL: https://externals.io/message/63408#63505 · In reply to: #63496 2012/10/17 Stas Malyshev > 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)