# supporting the final keyword for properties - Thread: https://externals.io/message/61289 - Original archive: https://news-web.php.net/php.internals/61289 - Started by Ferenc Kovacs on 2012-07-16T12:25:24+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 --- ## #61289 — Ferenc Kovacs — 2012-07-16T12:25:24+00:00 URL: https://externals.io/message/61289#61289 Hi, The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html discussion made me wonder why did we decide not supporting the final keywords for properties as it would provide an easy way for read-only attributes (const would be a better choice in performance wise, but then you can only set it in your declaration where no dynamic expression is allowed.) I would like it to work the same way as it does in java( http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) eg. you can set the initial value either in the declaration or later on, but after it is set, you can't change it, trying to do that would create a recoverable fatal error (or throwing an exception which extends RuntimeException). What do you think? Would this be viable? Is there any still-present reason why we shouldn't support that? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #61290 — Andrew Faulds — 2012-07-16T12:45:55+00:00 URL: https://externals.io/message/61289#61290 · In reply to: #61289 C# does this with the readonly keyword, sounds like a good idea. > Hi, > > The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) eg. > you can set the initial value either in the declaration or later on, but > after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- Andrew Faulds (AJF) http://ajf.me/ --- ## #61291 — Anthony Ferrara — 2012-07-16T12:59:12+00:00 URL: https://externals.io/message/61289#61291 · In reply to: #61289 Ferenc, > Hi, > > The recent > http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) > eg. > you can set the initial value either in the declaration or later on, but > after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? > My question would be where in code would this be enforced? A trivial implementation could be done in the object.write_property handler. But wouldn't things like references and the such (read_property and get_property_ptr_ptr, as well as get_properties) also be paths to writability? Would that then mean that this would need to be added to the zval type directly, and not just the property table? And if that's the case, why not make it final for the entire engine (meaning that I can declare a global property as final using `final $var = 1;`)... Thereby making this a rather significant engine changes? Or is there an easier way that I'm missing...? Anthony --- ## #61294 — Ferenc Kovacs — 2012-07-16T13:25:53+00:00 URL: https://externals.io/message/61289#61294 · In reply to: #61291 On Mon, Jul 16, 2012 at 2:59 PM, Anthony Ferrara wrote: > Ferenc, > > > > > […] > > My question would be where in code would this be enforced? A trivial > implementation could be done in the object.write_property handler. But > wouldn't things like references and the such (read_property and > get_property_ptr_ptr, as well as get_properties) also be paths to > writability? > > Would that then mean that this would need to be added to the zval type > directly, and not just the property table? And if that's the case, why not > make it final for the entire engine (meaning that I can declare a global > property as final using `final $var = 1;`)... Thereby making this a rather > significant engine changes? Or is there an easier way that I'm missing...? > > Anthony > Introducting final for the procedural code would be a bad idea imo, but on the other hand it would be in sync with the fact that we added the const keyword to be used in the global scope for example. About whether we should handle it in the zval or in the object.write_property I also don't have a strong opinion, I see both cons and pros. Another thing: If implemented, we should add a few methods to Reflection like: - ReflectionProperty::isFinal(void) - ReflectionProperty::setFinal(bool $final) -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #61295 — Nikita Popov — 2012-07-16T13:35:41+00:00 URL: https://externals.io/message/61289#61295 · In reply to: #61289 > Hi, > > The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) eg. > you can set the initial value either in the declaration or later on, but > after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? I don't like this overloaded meaning of "final". "final" currently means "cannot be overwritten by inheritance". This would add a second meaning which would be somewhat similar to "const" (but only somewhat). Nikita --- ## #61297 — Pierre Joye — 2012-07-16T13:42:19+00:00 URL: https://externals.io/message/61289#61297 · In reply to: #61289 hi, > The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) Final and readonly are too totally different concepts. Read only properties can be implemented by doing something using the nice getter/setter RFC (https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #61298 — Andrew Faulds — 2012-07-16T13:44:06+00:00 URL: https://externals.io/message/61289#61298 · In reply to: #61295 In that case, we should use what C# calls it, "readonly". Writable only once by the constructor. > > > […] > > I don't like this overloaded meaning of "final". "final" currently > means "cannot be overwritten by inheritance". This would add a second > meaning which would be somewhat similar to "const" (but only > somewhat). > > Nikita > > -- > > > -- Andrew Faulds (AJF) http://ajf.me/ --- ## #61300 — Amaury Bouchard — 2012-07-16T13:46:12+00:00 URL: https://externals.io/message/61289#61300 · In reply to: #61289 It could be useful (given the example of Java usage). But still, if the goal is to have read-only attributes, I think my proposal (separate reading and writing visibilities) is more precise and powerful. 2012/7/16 Ferenc Kovacs > Hi, > > The recent > http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) > eg. > you can set the initial value either in the declaration or later on, but > after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #61301 — Ferenc Kovacs — 2012-07-16T13:48:02+00:00 URL: https://externals.io/message/61289#61301 · In reply to: #61297 > hi, > > > > > […] > http://www.mail-archive.com/internals@lists.php.net/msg59301.html > > […] > (const > > […] > it > > […] > > Final and readonly are too totally different concepts. > except in those programming languages, where declaring attributes as final does the same thing. > > Read only properties can be implemented by doing something using the > nice getter/setter RFC > (https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented). > > thats true, maybe we should drop this thread until that RFC gets voted on. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #67572 — Ferenc Kovacs — 2013-05-28T06:15:09+00:00 URL: https://externals.io/message/61289#67572 · In reply to: #61289 > Hi, > > The recent > http://www.mail-archive.com/internals@lists.php.net/msg59301.html discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) > eg. you can set the initial value either in the declaration or later on, > but after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > the accessors rfc got rejected, so I'm bringing this up again. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #67578 — Lars Strojny — 2013-05-28T08:58:33+00:00 URL: https://externals.io/message/61289#67578 · In reply to: #67572 Hi Ferenc, Am 28.05.2013 um 08:15 schrieb Ferenc Kovacs : [...] > > […] [...] > the accessors rfc got rejected, so I'm bringing this up again. It’s a good idea in general but what about having it for variables as well? Could open interesting possibilities for an optimizer. final $foo = "str"; $foo = "bar"; // bails out cu, Lars --- ## #67580 — Amaury Bouchard — 2013-05-28T09:20:10+00:00 URL: https://externals.io/message/61289#67580 2013/5/28 Maciek Sokolewicz > It’s a good idea in general but what about having it for variables as > > […] It's different. You can manipulate variables in some ways you can't with constants. This code, for example: $a = 'abc'; $b = 'a'; print($$b); It will display "abc". It's currently not possible to do something similar with constants. I think the subject was already debated, but I wonder why we should write that: final $foo = 'bar'; instead of: const $foo = 'bar'; --- ## #67581 — Sebastian Krebs — 2013-05-28T09:26:55+00:00 URL: https://externals.io/message/61289#67581 · In reply to: #67580 2013/5/28 Amaury Bouchard > 2013/5/28 Maciek Sokolewicz > > > […] > > > It's different. You can manipulate variables in some ways you can't with > constants. > > This code, for example: > $a = 'abc'; > $b = 'a'; > print($$b); > > It will display "abc". It's currently not possible to do something similar > with constants. > define('FOO', 'bar'); $b = 'FOO'; print(constant($b)); and yes, `constant()` works for namespace- and class-constants too. > > I think the subject was already debated, but I wonder why we should write > that: > final $foo = 'bar'; > instead of: > const $foo = 'bar'; > -- github.com/KingCrunch --- ## #67582 — Amaury Bouchard — 2013-05-28T09:34:31+00:00 URL: https://externals.io/message/61289#67582 · In reply to: #67581 2013/5/28 Sebastian Krebs > print($$b); > > […] > > print(constant($b)); > It's definitely different. In your example you have to know that you are manipulating constants only. --- ## #67583 — Ferenc Kovacs — 2013-05-28T09:50:23+00:00 URL: https://externals.io/message/61289#67583 · In reply to: #67578 > Hi Ferenc, > > Am 28.05.2013 um 08:15 schrieb Ferenc Kovacs : > [...] > > […] > create a > > […] > reason > > […] > [...] > > […] > > It’s a good idea in general but what about having it for variables as > well? Could open interesting possibilities for an optimizer. > > final $foo = "str"; > $foo = "bar"; // bails out > > cu, > Lars I think that this proposal only makes sense in a class context. For your example we already have a solution: constants. Unfortunately class constants has more limitation, as you can't assign expressions to them, and using global(namespaced) constants which will be only used in that class breaks the encapsulation part of OOP, as your constants are "leaking" out. One solution would be to allow the class consts to accept expressions, but for that the simple solution would slow down the class constanst for everybody. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #67585 — Sebastian Krebs — 2013-05-28T10:59:24+00:00 URL: https://externals.io/message/61289#67585 · In reply to: #67582 2013/5/28 Amaury Bouchard > 2013/5/28 Sebastian Krebs > > > […] > > It's definitely different. In your example you have to know that you are > manipulating constants only. > > And in your example you have to know, that you are "manipulating" a variable :? -- github.com/KingCrunch --- ## #67587 — Amaury Bouchard — 2013-05-28T12:44:14+00:00 URL: https://externals.io/message/61289#67587 · In reply to: #67585 2013/5/28 Sebastian Krebs > > And in your example you have to know, that you are "manipulating" a > variable :? > > Sure. But my example's goal was to show the idea of Lars. Using the "final" keyword on variables would allow to manipulate variables and "constant variables", without the need to know if it's a variable or a constant (obviously because they are all variables). Not my idea, I was just explaining. --- ## #67588 — Robert Stoll — 2013-05-28T13:29:00+00:00 URL: https://externals.io/message/61289#67588 · In reply to: #67587 In my opinion read-only variables are not the same as constants. You could do something as following: final $foo = new Foo(); and that is definitely not the same as a constant. However, I guess this new feature would slow down the parsing process and therefore I am against it. -----Ursprüngliche Nachricht----- Von: amaury.bouchard@gmail.com [mailto:amaury.bouchard@gmail.com] Im Auftrag von Amaury Bouchard Gesendet: Dienstag, 28. Mai 2013 13:44 An: Sebastian Krebs Cc: Maciek Sokolewicz; Lars Strojny; Ferenc Kovacs; PHP Internals Betreff: Re: [PHP-DEV] supporting the final keyword for properties 2013/5/28 Sebastian Krebs > > And in your example you have to know, that you are "manipulating" a > variable :? > > Sure. But my example's goal was to show the idea of Lars. Using the "final" keyword on variables would allow to manipulate variables and "constant variables", without the need to know if it's a variable or a constant (obviously because they are all variables). Not my idea, I was just explaining. --- ## #67589 — Levi Morrison — 2013-05-28T14:23:36+00:00 URL: https://externals.io/message/61289#67589 · In reply to: #67588 > However, I guess this new feature would slow down the parsing process and > therefore I am against it. It might slow the process down because on every assignment you have to make sure it's not a final variable. Until we really know how much that slows it down, I'm not sure that is much of an issue. We should really focus on deciding whether or not we want the 'final' functionality.