# [RFC] Readonly Properties - Thread: https://externals.io/message/78284 - Original archive: https://news-web.php.net/php.internals/78284 - Started by Andrea Faulds on 2014-10-23T23:36:35+00:00 - Messages: 41 - RFC: Readonly Properties (Withdrawn) — https://externals.io/rfc/readonly_properties.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/78284.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #78284 — Andrea Faulds — 2014-10-23T23:36:35+00:00 URL: https://externals.io/message/78284#78284 Good evening once again, Here’s another RFC: https://wiki.php.net/rfc/readonly_properties It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. Thanks! -- Andrea Faulds http://ajf.me/ --- ## #78286 — Xinchen Hui — 2014-10-24T03:02:32+00:00 URL: https://externals.io/message/78284#78286 · In reply to: #78284 Hey: > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. > > Thanks! Hey: -1 on this. Actually, your example for explaining usage.. I don't see why it is must, add a getSize() will also meet the needs, and more beatiful, as you can change $size to another name if you like later. thanks > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #78287 — Kalle Sommer Nielsen — 2014-10-24T04:11:36+00:00 URL: https://externals.io/message/78284#78287 · In reply to: #78286 Hi 2014-10-24 5:02 GMT+02:00 Xinchen Hui : > Hey: > > -1 on this. > > Actually, your example for explaining usage.. > > I don't see why it is must, add a getSize() will also meet the > needs, and more beatiful, as you can change $size to another name if > you like later. I disagree on your disagreement, while it is not a must, it does not make much sense that we are gonna call what essential is a function to return a value that is not changed in anyway during that call. It does not really perform a function, other than returning a value in 99% of all cases, and therefore it makes perfect sense to allow readonly properties in my mind. It does not really make the code beautiful to prefix it with 'get' and suffix it with '()' when you want such a value, it makes it consistent, yes, but else it is just bloat to my eyes. Internally it should also be a slightly be faster to not having to call a method everytime as well, a program that does, lets say 50-100 calls to 'getX()' that can skip INIT_METHOD_CALL + DO_FCALL_BY_NAME and instead just a FETCH_OBJ_R which is what should be after the fcall, micro optimization I know (been a while since I went into these parts so I might be a bit off though). I'm a huge +1 on this, good job Andrea! -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #78288 — Xinchen Hui — 2014-10-24T05:09:37+00:00 URL: https://externals.io/message/78284#78288 · In reply to: #78287 > Hi > > 2014-10-24 5:02 GMT+02:00 Xinchen Hui : > > […] > > I disagree on your disagreement, while it is not a must, it does not > make much sense that we are gonna call what essential is a function to > return a value that is not changed in anyway during that call. It does > not really perform a function, other than returning a value in 99% of > all cases, and therefore it makes perfect sense to allow readonly > properties in my mind. > > It does not really make the code beautiful to prefix it with 'get' and > suffix it with '()' when you want such a value, it makes it > consistent, yes, but else it is just bloat to my eyes. so you prefer to expose the name of the property anywhere? let's say you expose a readonly int value name iSize.. but later, the value also need to be a double, then you also prefer add another dval? (since you can not simple change ival name, since it was exposed) > > Internally it should also be a slightly be faster to not having to > call a method everytime as well, a program that does, lets say 50-100 > calls to 'getX()' that can skip INIT_METHOD_CALL + DO_FCALL_BY_NAME > and instead just a FETCH_OBJ_R which is what should be after the > fcall, micro optimization I know (been a while since I went into these > parts so I might be a bit off though). I knew this of course, but this is actually not related to this specific "readonly" RFC but if you are strict to this., then I'd like to say, this will slowdown all FETCH_OBJ_R a bit, since this will need introduce a condition to check whether a property is readonly.. only faster a narrow case... thanks > > I'm a huge +1 on this, good job Andrea! > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #78292 — Andrea Faulds — 2014-10-24T07:50:15+00:00 URL: https://externals.io/message/78284#78292 · In reply to: #78288 > > so you prefer to expose the name of the property anywhere? > > let's say you expose a readonly int value name iSize.. > > but later, the value also need to be a double, > > then you also prefer add another dval? (since you can not simple > change ival name, since it was exposed) Is that not already a problem with functions? You can't change their names. If you do change its name, you can add a __get. > I knew this of course, but this is actually not related to this > specific "readonly" RFC > > but if you are strict to this., then I'd like to say, this will > slowdown all FETCH_OBJ_R a bit, since this will need introduce a > condition to check whether a property is readonly.. only faster a > narrow case... Right, it will theoretically make public and protected property lookups ever-so-slightly slower. I'll need to benchmark it as I doubt it's a big deal in practice. Though this could be worked around by making the write check be a different function. Or by inlining. -- Andrea Faulds http://ajf.me/ --- ## #78293 — Rowan Collins — 2014-10-24T08:12:52+00:00 URL: https://externals.io/message/78284#78293 · In reply to: #78284 >Good evening once again, > >Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > >It proposes, with a working implementation, a modifier for properties >that makes them readable and writeable from different scopes. > >Since I am a big proponent of including specification patches in new >RFCs, I have decided to put my money (or rather, time) where my mouth >is and I have actually written a specification patch before writing an >RFC. I would love to see this become the new standard for RFCs >affecting the language. > >If you are curious at all about the behaviour, I suggest perusing the >fairly comprehensive set of twelve tests included in the main patch to >php-src. > >Thanks! >-- >Andrea Faulds >http://ajf.me/ If nothing else, I like that this brings userland objects another step closer to those defined in extensions, which frequently use readonly properties. I note that UString advertises a ->length rather than a ->getLength, and I haven't seen anyone in that thread object to that design decision, so I don't really buy the "you should never need this" argument. The additional keyword and potential performance impact are more concerning, and will need to be weighed carefully against the benefits. --- ## #78294 — Andrey Andreev — 2014-10-24T08:35:09+00:00 URL: https://externals.io/message/78284#78294 · In reply to: #78284 Hi, > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. +1 I've always wanted this, it has never made sense to me to write numerous lines of code just to make an already declared property *readable* from outside a class. __get() has helped to some extent, but it has its disadvantages. Cheers, Andrey. --- ## #78295 — Patrick Schaaf — 2014-10-24T08:41:38+00:00 URL: https://externals.io/message/78284#78295 · In reply to: #78284 Am 24.10.2014 01:36 schrieb "Andrea Faulds" : > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties +1 for the general feature, I'd love to have that available. I have an idea regarding the additional keyword, with a small implication (improvement) to the functionality provided, but at the cost of being slightly quirky :) The idea is: public $foo as private; public $bar as protected; protected $baz as private; where the "as X" gives the writability scope. This introduces no new keywords, and is currently not valid syntax, as far as I can see. best regards Patrick --- ## #78296 — Jordi Boggiano — 2014-10-24T09:29:25+00:00 URL: https://externals.io/message/78284#78296 · In reply to: #78284 > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties > that makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new > RFCs, I have decided to put my money (or rather, time) where my mouth > is and I have actually written a specification patch before writing > an RFC. I would love to see this become the new standard for RFCs > affecting the language. Thanks for the work (again). It's an interesting small idea but I'd much prefer revisiting the original getter/setter RFC [1] which had a majority but just fell short of the 66% mark. This RFC only implements parts of the getter/setter functionality (readonly properties) but it does not address the fact that sometimes you want to add logic to a setter or a getter and if you don't have language level getters/setters you end up having to change the interface of the object from a public property to a getFoo/setFoo pair. This leads to everyone having getFoo/setFoo by default just to avoid interface changes or mixed interfaces of public properties and setFoo. [1] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi --- ## #78297 — Pierre Joye — 2014-10-24T09:34:21+00:00 URL: https://externals.io/message/78284#78297 · In reply to: #78284 hi Andrea, > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. As much i really like the idea to have better properties management in PHP I see this RFC as an attempt to solve only part of the problem while dropping most of the other ideas implemented in the past RFCs. My take on that is that some will vote no, or won't like the idea of adding anything in this area. Making compromises and implement partial solutions will only delay the implementation of the complete solution. Many of us agree that __get/__set is a pain to deal with.The need of readonly, writeonly or properties with some logic to define or get a value is a lond due need. Many other languages support that out of the box since long already. Past RFCs, like the c# one, proposed that. I would rather focus on trying to find an acceptable syntax and implementation instead of doing baby steps like that. Baby steps work very well for scalar type hinting, solving one issue after another, etc. But for properties we are at the risk of hainvg a serie of separate RFCs solving the properties management problems in different ways bringing even more troubles and inconsistencies. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #78298 — Nikita Popov — 2014-10-24T10:20:06+00:00 URL: https://externals.io/message/78284#78298 · In reply to: #78284 > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that > makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, > I have decided to put my money (or rather, time) where my mouth is and I > have actually written a specification patch before writing an RFC. I would > love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the > fairly comprehensive set of twelve tests included in the main patch to > php-src. > > Thanks! > While I think the functionality behind this proposal is nice in principle, I have two objections with the RFC: 1. It uses the "readonly" modifier, to refer to a property that is publicly readable, but protectedly writable (or protectedly readable and privately writable). This isn't entirely obvious from the term "readonly" and also does not match the behavior of other languages employing a "readonly" modifier, like C#. An additional complication may be encountered in the case where the readonly property stores an object, in which case I presume it will be possible to modify the stored object ($obj->readonlyProp->prop = 42), which is likely not expected "readonly" behavior. 2. If the aim of this RFC is to replace the getFoo() pattern with the use of "readonly public $foo" properties, a primary difference will be that a getFoo() method can be declared in an interface, whereas a "readonly public $foo" property cannot be. Thus code making use of interfaces will not be able to employ this feature. And I don't think that allowing properties in interfaces is reasonable at this point, because the implementations will be limited to simple-storage properties - only with more comprehensive property accessor support would implementations be allowed to use more complex backing code. For these reasons I do not think this RFC is suitable for inclusion in PHP in its current state. As others in this thread have already pointed out, it may be advisable to reconsider readonly properties in the broader context of property accessors. Nikita --- ## #78299 — Alain Williams — 2014-10-24T10:21:57+00:00 URL: https://externals.io/message/78284#78299 · In reply to: #78295 > Am 24.10.2014 01:36 schrieb "Andrea Faulds" : > > […] > > +1 for the general feature, I'd love to have that available. > > I have an idea regarding the additional keyword, with a small implication > (improvement) to the functionality provided, but at the cost of being > slightly quirky :) The idea is: > > public $foo as private; > public $bar as protected; > protected $baz as private; > > where the "as X" gives the writability scope. This introduces no new > keywords, and is currently not valid syntax, as far as I can see. More as musing than anything else - might provide some insight via an analogy. Properties and methods have a scope that is: private, protected or public. This reminds me of the Unix: owner, group & other file permissions. Unix allows: read, write & execute. This RFC is trying to control how a property could be used with a readonly restriction. Are there times when one would want to be able to set a property value - but not read it ? Thinking about execute - would there be any mileage in an execute permission - could be useful for a property that had been assigned an anonymous function. Finally we could bring it all together and sidestep the scoping keywords using 'var' instead. Thus: var $callback as 0751; Would define a property that contains an anonymous function that could be called by anyone, inspected by the class & related class, but only set by the class itself! -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include > > […] > > More as musing than anything else - might provide some insight via an > analogy. > > Properties and methods have a scope that is: private, protected or public. > This reminds me of the Unix: owner, group & other file permissions. > > Unix allows: read, write & execute. > > This RFC is trying to control how a property could be used with a readonly > restriction. > Are there times when one would want to be able to set a property value - > but not > read it ? > > Thinking about execute - would there be any mileage in an execute > permission - > could be useful for a property that had been assigned an anonymous > function. > > > Finally we could bring it all together and sidestep the scoping keywords > using > 'var' instead. Thus: > > var $callback as 0751; > > Would define a property that contains an anonymous function that could be > called > by anyone, inspected by the class & related class, but only set by the > class itself! > To follow up on this, and to give more readable code, we could also use this: var $callback as rwxrw---x; > > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 http://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > http://www.phcomp.co.uk/contact.php > #include > > -- > > > > Regards, -- Florian Margaine --- ## #78301 — Alain Williams — 2014-10-24T10:37:07+00:00 URL: https://externals.io/message/78284#78301 · In reply to: #78300 > > […] > > To follow up on this, and to give more readable code, we could also use > this: > > var $callback as rwxrw---x; +1, although that would have been: var $callback as rwxr-x--x; Again musing further: var $callback as rwsr-x--x; A callback that when executed/called would have 'private' access permissions on properties! -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include hi Andrea, > > > > […] > > As much i really like the idea to have better properties management in > PHP I see this RFC as an attempt to solve only part of the problem > while dropping most of the other ideas implemented in the past RFCs. > My take on that is that some will vote no, or won't like the idea of > adding anything in this area. Making compromises and implement partial > solutions will only delay the implementation of the complete solution. > > Many of us agree that __get/__set is a pain to deal with.The need of > readonly, writeonly or properties with some logic to define or get a > value is a lond due need. Many other languages support that out of the > box since long already. Past RFCs, like the c# one, proposed that. I > would rather focus on trying to find an acceptable syntax and > implementation instead of doing baby steps like that. Baby steps work > very well for scalar type hinting, solving one issue after another, > etc. But for properties we are at the risk of hainvg a serie of > separate RFCs solving the properties management problems in different > ways bringing even more troubles and inconsistencies. Pierre, I rarely disagree with you, but this is one such case. It is true that we can look at this as a partial solution to a bigger problem, or as you said - a baby step. However, I see this as the perfect solution for a very narrow, yet also a very common problem, and I don't see it blocking a more abstract solution in the future. From a userland POV, it is simple, very effective and there's practically no way to achieve the same goal with less amount of code. In short - it's no panacea to all the limitations that we currently have on property management, but it is still *extremely* useful for implementing classes that only need to have getters. On another note, I share Nikita's concern about using the "readonly" keyword and I'd love that to be improved, but the best alternative I could think of is "readable" and IMO it doesn't have a clearer meaning. Cheers, Andrey. --- ## #78303 — Andrea Faulds — 2014-10-24T11:54:06+00:00 URL: https://externals.io/message/78284#78303 · In reply to: #78296 > > > Thanks for the work (again). It's an interesting small idea but I'd much prefer revisiting the original getter/setter RFC [1] which had a majority but just fell short of the 66% mark. > > This RFC only implements parts of the getter/setter functionality (readonly properties) but it does not address the fact that sometimes you want to add logic to a setter or a getter and if you don't have language level getters/setters you end up having to change the interface of the object from a public property to a getFoo/setFoo pair. > > This leads to everyone having getFoo/setFoo by default just to avoid interface changes or mixed interfaces of public properties and setFoo. > > > > As much i really like the idea to have better properties management in > PHP I see this RFC as an attempt to solve only part of the problem > while dropping most of the other ideas implemented in the past RFCs. > My take on that is that some will vote no, or won't like the idea of > adding anything in this area. Making compromises and implement partial > solutions will only delay the implementation of the complete solution. > > Many of us agree that __get/__set is a pain to deal with.The need of > readonly, writeonly or properties with some logic to define or get a > value is a lond due need. Many other languages support that out of the > box since long already. Past RFCs, like the c# one, proposed that. I > would rather focus on trying to find an acceptable syntax and > implementation instead of doing baby steps like that. Baby steps work > very well for scalar type hinting, solving one issue after another, > etc. But for properties we are at the risk of hainvg a serie of > separate RFCs solving the properties management problems in different > ways bringing even more troubles and inconsistencies. I think I might be misunderstood, here. While getters and setters can do this, and I’m very much in favour of also reviving a simplified version of the getter/setter RFC (previous one was way too complex), I don’t see this as partly implementing them/baby steps/etc. I fact, I think readonly properties could work together with getters/setters. I don't like using property getters and setters to control whether a property can be written to or read from. I think they're the wrong solution for that - why have a virtual property with boilerplate restricted visibility accessors and mutators that get/set a hidden private property, with their associated performance penalties, when you can just make a real property that can't be read by outsiders? I think getters and setters are useful and I probably will try to revive them too sometime soon, but I think they’re actually the wrong tool for this specific job. -- Andrea Faulds http://ajf.me/ --- ## #78304 — Andrea Faulds — 2014-10-24T11:59:18+00:00 URL: https://externals.io/message/78284#78304 · In reply to: #78298 > > > While I think the functionality behind this proposal is nice in principle, I have two objections with the RFC: > > 1. It uses the "readonly" modifier, to refer to a property that is publicly readable, but protectedly writable (or protectedly readable and privately writable). This isn't entirely obvious from the term "readonly" and also does not match the behavior of other languages employing a "readonly" modifier, like C#. An additional complication may be encountered in the case where the readonly property stores an object, in which case I presume it will be possible to modify the stored object ($obj->readonlyProp->prop = 42), which is likely not expected "readonly" behavior. It’s not the best name, I agree, but there isn’t a better name I could come up with in discussions. I don’t think the object thing is an issue, it’s not like there’s much we can do about that. > > 2. If the aim of this RFC is to replace the getFoo() pattern with the use of "readonly public $foo" properties, a primary difference will be that a getFoo() method can be declared in an interface, whereas a "readonly public $foo" property cannot be. Thus code making use of interfaces will not be able to employ this feature. And I don't think that allowing properties in interfaces is reasonable at this point, because the implementations will be limited to simple-storage properties - only with more comprehensive property accessor support would implementations be allowed to use more complex backing code. Right, interfaces currently can’t declare properties and I’m not going to change that in this RFC. If I revisit getters and setters, that would be changed. Still, I think there is usefulness to this without interfaces… it’s just more limited, sadly. It would work quite well with getters and setters and interfaces, if later added. Within interfaces, readonly could be used to avoid compelling implementing classes to support writing: interface Point { public readonly $x, $y; } But without preventing implementing classes from supporting it. -- Andrea Faulds http://ajf.me/ --- ## #78305 — Andrea Faulds — 2014-10-24T12:03:39+00:00 URL: https://externals.io/message/78284#78305 · In reply to: #78302 > > > Pierre, I rarely disagree with you, but this is one such case. > > It is true that we can look at this as a partial solution to a bigger > problem, or as you said - a baby step. However, I see this as the > perfect solution for a very narrow, yet also a very common problem, > and I don't see it blocking a more abstract solution in the future. That’s basically my thoughts on this RFC. I think it’s still quite useful even if it’s not as useful as it could be without certain other additions. > > From a userland POV, it is simple, very effective and there's > practically no way to achieve the same goal with less amount of code. > > In short - it's no panacea to all the limitations that we currently > have on property management, but it is still *extremely* useful for > implementing classes that only need to have getters. It’s also faster! > On another note, I share Nikita's concern about using the "readonly" > keyword and I'd love that to be improved, but the best alternative I > could think of is "readable" and IMO it doesn't have a clearer > meaning. Yeah, that’s the problem. It is somewhat unclear, but any other keyword choice is even more confusing. I discussed this quite a bit in StackOverflow’s PHP chatroom (http://chat.stackoverflow.com/rooms/11/php) and couldn’t come up with anything better. Also, as I note in the RFC, we already use readonly in the docs for some classes, and for C#-style only-set-once read-only properties, we could use final or immutable. -- Andrea Faulds http://ajf.me/ --- ## #78306 — Andrea Faulds — 2014-10-24T12:12:30+00:00 URL: https://externals.io/message/78284#78306 · In reply to: #78304 > > > > […] > > Right, interfaces currently can’t declare properties and I’m not going to change that in this RFC. If I revisit getters and setters, that would be changed. Still, I think there is usefulness to this without interfaces… it’s just more limited, sadly. > > It would work quite well with getters and setters and interfaces, if later added. Within interfaces, readonly could be used to avoid compelling implementing classes to support writing: > > interface Point { > public readonly $x, $y; > } > > But without preventing implementing classes from supporting it. I added a little Future Scope section on this: https://wiki.php.net/rfc/readonly_properties#puture_scope -- Andrea Faulds http://ajf.me/ --- ## #78318 — Stas Malyshev — 2014-10-24T23:34:03+00:00 URL: https://externals.io/message/78284#78318 · In reply to: #78284 Hi! > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. For me, this seems both too big and too small. Too small, because if you really it assigns a keyword to special use case of a generic feature, and thus I think does not lead us on the right path - we could not assign keywords to every behavior of properties, so either we forever reject the idea of having any generic solution there, or we'd eventually have two solutions, working in two different ways. Too big because this particular case is already very easy to implement by just making the property protected and having a public getter. It doesn't add any capability that we already don't have, and having a keyword just to save typing () seems unnecessary to me (performance is really irrelevant here, if your performance is bound by speed of accessors, you should be writing that code in C). Also, the name "readonly" appears misleading as it's not really read only - it's only read only for some classes, but writeable for others. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78319 — Kalle Sommer Nielsen — 2014-10-24T23:39:32+00:00 URL: https://externals.io/message/78284#78319 · In reply to: #78288 2014-10-24 7:09 GMT+02:00 Xinchen Hui : > so you prefer to expose the name of the property anywhere? > > let's say you expose a readonly int value name iSize.. > > but later, the value also need to be a double, > > then you also prefer add another dval? (since you can not simple > change ival name, since it was exposed) That is purely a naming decision, not something that should cause the actual design of a language to not be available and even then, what you are saying seems like a very edge case to me and I have a hard time trying to understand if as I understand it, is your argument against this feature. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #78335 — Jordi Boggiano — 2014-10-26T10:30:50+00:00 URL: https://externals.io/message/78284#78335 · In reply to: #78303 > > > […] > > > […] > > I think I might be misunderstood, here. While getters and setters can > do this, and I’m very much in favour of also reviving a simplified > version of the getter/setter RFC (previous one was way too complex), > I don’t see this as partly implementing them/baby steps/etc. I fact, > I think readonly properties could work together with > getters/setters. Fair enough, thanks for the clarification. It also sounds good to have very simple getter/setters when needed and simple properties + eventually readonly otherwise. issetters/unsetters aren't extremely needed. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi --- ## #78352 — Rowan Collins — 2014-10-26T19:16:51+00:00 URL: https://externals.io/message/78284#78352 · In reply to: #78284 > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, I have decided to put my money (or rather, time) where my mouth is and I have actually written a specification patch before writing an RFC. I would love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the fairly comprehensive set of twelve tests included in the main patch to php-src. > > Thanks! I just had a thought on both the naming and future-proofing concerns of this proposal: what about pre-emptively reserving the skeleton of the syntax needed for accessors, without actually implementing them? For instance, one of the (confusingly many) syntaxes allowed by https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 would have been this: private $foo { public get; protected set; } In that instance, this was seen as short-hand for the default "proxy method", but the effect is to modify the visibility of the property without any extra behaviour. If we remove the requirement to specify both get and set if the guard clause is added, we get a simple syntax that covers the two cases the RFC's "readonly" keyword does, plus one more: // Current RFC public readonly $foo; // read public, write protected protected readonly $foo; // read protected, write private // With only "set" keyword public $foo { protected set; } protected $foo { private set; } public $foo { private set; } // read public, write private // With only "get" keyword protected $foo { public get; } private $foo { protected get; } private $foo { public get; } // With both keywords, since "var" has been undeprecated var $foo { public get; protected set; } var $foo { protected get; private set; } var $foo { public get; private set; } This syntax does imply other combinations like "private get; public set;" (effectively "write-only" from certain scopes), which may complicate matters somewhat. To keep things simple, we could simply enforce a rule at compile time that "read visibility must not be more restrictive than write visibility". This gets rid of the ambiguity of the "readonly" keyword, and makes the behaviour of "read protected, write private" much more obvious. It also opens the door to syntax for accessors without placing much restriction on how they could work... // Forwards compatible to all these and more... var $foo { public get { return $this->bar * 10; } private set; } var $foo { public get() { return $this->bar * 10; } private set; } var $foo { public get => $this->bar * 10; private set; } var $foo { public get: existingMethod; private set; } -- Rowan Collins [IMSoP] --- ## #78400 — Dmitry Stogov — 2014-10-27T18:31:45+00:00 URL: https://externals.io/message/78284#78400 · In reply to: #78284 Hi Andrea, I don't have strong opinion about this proposal. It doesn't make any harm to the engine, and it really may speed-up code especially written for read-only properties. On the other hand you introduce new orthogonal to private/protected/public visibility rule, and I'm not sure if this complication is good for language. Why did you disable read-only static methods? (I just didn't get it). Thanks. Dmitry. > Good evening once again, > > Here’s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties that > makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs, > I have decided to put my money (or rather, time) where my mouth is and I > have actually written a specification patch before writing an RFC. I would > love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the > fairly comprehensive set of twelve tests included in the main patch to > php-src. > > Thanks! > -- > Andrea Faulds > http://ajf.me/ --- ## #78401 — Andrea Faulds — 2014-10-27T19:25:05+00:00 URL: https://externals.io/message/78284#78401 · In reply to: #78400 > > > Hi Andrea, > > I don't have strong opinion about this proposal. > It doesn't make any harm to the engine, and it really may speed-up code especially written for read-only properties. > On the other hand you introduce new orthogonal to private/protected/public visibility rule, > and I'm not sure if this complication is good for language. > > Why did you disable read-only static methods? (I just didn't get it). You couldn't really have a read-only method, there's no get/set equivalent for methods. The reason they're explicitly disallowed in the code is because, to avoid shift/reduce conflicts, I have to add it as a member modifier but then check the AST to see if it was used. The reason for disallowing static methods is we currently don't use separate code paths for get/set of static methods, we just call one function to obtain a pointer. Of course I could make that function be told whether it's for writing, I just hadn't done it yet. -- Andrea Faulds http://ajf.me/ --- Next page: https://externals.io/message/78284.md?page=2