# [RFC][DISCUSSION] - Immutable classes and properties - Thread: https://externals.io/message/97355 - Original archive: https://news-web.php.net/php.internals/97355 - Started by marijic.silvio@gmail.com on 2016-12-11T16:57:32+00:00 - Messages: 25 - RFC: Immutable classes and properties (Obsolete) — https://externals.io/rfc/immutability.md - 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 --- ## #97355 — marijic.silvio@gmail.com — 2016-12-11T16:57:32+00:00 URL: https://externals.io/message/97355#97355 Hi, Discussion is open for following rfc https://wiki.php.net/rfc/immutability Cheers --- ## #97356 — Larry Garfield — 2016-12-11T19:59:49+00:00 URL: https://externals.io/message/97355#97356 · In reply to: #97355 > Hi, > > Discussion is open for following rfc https://wiki.php.net/rfc/immutability > > Cheers > Some grammar issues: "After object is constructor" => should be "After the object's constructor has run". " If immutable property contains object, to preserve immutability, object that is beeing assigned to immutable property must also immutable." => "If an immutable property contains an object, then in order to preserve immutability the object being assigned must be of an immutable class." The File class/resource example should note that the last line in it will create a fatal error, as the earlier examples do. It's not clear that the example is an invalid one. In a few places, "If immutable property..." should be "If an immutable property..." There's several places where articles (the, an, etc.) are missing. "Notice in above examples removing getters and setting properties to public is optional. They simply doesn't need to be protected anymore in fact that immutable class objects are deeply frozen with eceptions on write." => "Notice in the above examples that removing getters and setting properties to public are optional. They simply don't need to be protected given the fact that immutable class objects are frozen on write." (Several grammar fixes, plus it's a fatal error, not an exception.) Content issues: Currently the only "unlocked context" for an object is its constructor. As discussed previously, that is insufficient. For any non-trivial object (more than 1-3 internal properties) creating a new one via the constructor only when incrementally building is prohibitively difficult. The pattern of with*() methods that spawn new objects via `clone()`, a la PSR-7, needs to be supported. That is: immutable class Money { // ... public function add(Money $other) : Money { $new = clone($this); $new->amount += $other->amount; return $new; } } I'm not sure how easily we can denote that sort of case. It's outside the __clone() function itself, which is what makes it difficult. Without that, though, such immutable objects are of only limited use. --Larry Garfield --- ## #97357 — Marcio Almada — 2016-12-11T22:35:01+00:00 URL: https://externals.io/message/97355#97357 · In reply to: #97355 2016-12-11 12:57 GMT-04:00 Silvio Marijić : > Hi, > > Discussion is open for following rfc https://wiki.php.net/rfc/immutability > > Cheers > Hi, Can you make a pull request? I'd like to comment the patch but it's not possible to make inline reviews only with a diff uri on github. --- ## #97358 — marijic.silvio@gmail.com — 2016-12-11T23:30:05+00:00 URL: https://externals.io/message/97355#97358 · In reply to: #97357 @Larry, first of all thanks for pointing out grammar issues, I will correct them. Now, regarding cloning of the immutable object, I'm aware of that issue and I'm not sure if we could even use clone operation for this purpose, I do have one proposal for that matter, consider example: immutable class User { public $firstname; public $lastname; public $email; public function __construct($firstname, $lastname, $email){ // } } $user = new User('Foo', 'Bar', 'foo@bar.com'); $new = copy($user, ['firstname' => 'John', 'email' => 'john@bar.com']) Copy function would take as a first argument an immutable object and as a second argument associative array where keys represent property names and values specified will be assigned to those properties on a new object. @Marcio I will submit PR, have you found bug or? Cheers 2016-12-11 23:35 GMT+01:00 Marcio Almada : > > 2016-12-11 12:57 GMT-04:00 Silvio Marijić : > > > […] > > > Hi, > > Can you make a pull request? I'd like to comment the patch but it's not > possible to make inline reviews only with a diff uri on github. > > -- Silvio Marijić Software Engineer 2e Systems --- ## #97359 — Larry Garfield — 2016-12-12T00:03:43+00:00 URL: https://externals.io/message/97355#97359 Assuming this was intended for the list... > Currently the only "unlocked context" for an object is its > constructor. As discussed previously, that is insufficient. For any > non-trivial object (more than 1-3 internal properties) creating a new > one via the constructor only when incrementally building is > prohibitively difficult. The pattern of with*() methods that spawn > new objects via `clone()`, a la PSR-7, needs to be supported. That is: > > immutable class Money { > // ... > > public function add(Money $other) : Money { > $new = clone($this); > $new->amount += $other->amount; > return $new; > } > } > > I'm not sure how easily we can denote that sort of case. It's outside > the __clone() function itself, which is what makes it difficult. > Without that, though, such immutable objects are of only limited use. > > As you said, it has been already been discussed that a method to build > new altered object from an existing one could be improved. Different > options were proposed but maybe it's better to start small to get this > first part right and add this in another rfc ? having everything at the > same time might makes the rfc more difficult to be accepted On the contrary, an RFC that doesn't fully solve the issue at hand and leaves major gaps in place is a poor RFC, and I would expect to be justifiably voted down. --Larry Garfield --- ## #97360 — marijic.silvio@gmail.com — 2016-12-12T00:16:30+00:00 URL: https://externals.io/message/97355#97360 · In reply to: #97359 This have occurred to me also, I wanted to separate that into two RFC's, but then how we deal with RFC's that depend on each other? 2016-12-12 1:03 GMT+01:00 Larry Garfield : > Assuming this was intended for the list... > > > > > […] > > > > > […] > > On the contrary, an RFC that doesn't fully solve the issue at hand and > leaves major gaps in place is a poor RFC, and I would expect to be > justifiably voted down. > > --Larry Garfield > > -- > > > > -- Silvio Marijić Software Engineer 2e Systems --- ## #97361 — Mathieu Rochette — 2016-12-12T00:40:19+00:00 URL: https://externals.io/message/97355#97361 · In reply to: #97360 > This have occurred to me also, I wanted to separate that into two RFC's, > but then how we deal with RFC's that depend on each other? well that's just my opinion but I don't think they depend on each other, this rfc seems useful on its own. The "clone" one might depends on this one but it does not *need* to either (otoh it certainly would be much more useful with immutable classes than mutable classes) plus, this part might already trigger enough discussion and adding everything at once might get confusion. I can think of : clone, late initialization, DateTimeImmutable and probably other subjects that could make the discussion noisy I'm not as familiar as you are with this mailing list so I might very well be wrong too ^^ > > 2016-12-12 1:03 GMT+01:00 Larry Garfield : > > > […] it was, thank you > > […] > -- Mathieu Rochette --- ## #97363 — Davey Shafik — 2016-12-12T05:58:52+00:00 URL: https://externals.io/message/97355#97363 · In reply to: #97361 On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette wrote: > > > > > […] > well that's just my opinion but I don't think they depend on each other, > this rfc seems useful on its own. The "clone" one might depends on this > one but it does not *need* to either (otoh it certainly would be much > more useful with immutable classes than mutable classes) > > plus, this part might already trigger enough discussion and adding > everything at once might get confusion. I can think of : clone, late > initialization, DateTimeImmutable and probably other subjects that could > make the discussion noisy > > I'm not as familiar as you are with this mailing list so I might very > well be wrong too ^^ > > […] > it was, thank you > > […] > I wonder if we can essentially make all public methods act like they are static (no access to $this) and then use something like: immutable class Foo { protected $bar; public function getBar() with (Foo $instance): string // $instance is a clone of $this { // context == $instance, so access to private/protected return $instance->bar; } public function withBar($bar) with (Foo $instance): Foo { $instance->bar = $bar; // Allowed as we're in scope return $instance; } } Only operations in the scope of the class itself (and it's descendants, adhering to standard visibility rules) can make changes on the cloned variant. The `with ($instance)` is optional, $instance is just a variable name. In reality you'll want to use it most of the time I imagine. I suppose you can re-use the `use` keyword here too. Also, this shouldn't allow for immutable properties. Another option is to look at the way that HHVM does immutable types, though that is _file_ based. - Davey --- ## #97364 — marijic.silvio@gmail.com — 2016-12-12T09:11:17+00:00 URL: https://externals.io/message/97355#97364 · In reply to: #97363 @Davey, There was similar suggestion that $this represents clone of the object. I think that is a bit vague, and I'am not sure about the 'scope' you refer to because 'double scoping' could be also a reason to downvote this rfc and it can lead to confusion in my opinion. I will check HHVM also. Regarding my proposal above, since `copy()` would essentially operate only on immutable objects, why not put it only there. So you would be able to make a call like this one $immutable->copy(array $args); or $this->copy(array $args); depending on whether you are inside let's say with* method or outside of the object. 2016-12-12 6:58 GMT+01:00 Davey Shafik : > On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette > wrote: > > > […] > > I wonder if we can essentially make all public methods act like they are > static (no access to $this) and then use something like: > > immutable class Foo { > protected $bar; > public function getBar() with (Foo $instance): string // $instance is > a clone of $this > { > // context == $instance, so access to private/protected > return $instance->bar; > } > > public function withBar($bar) with (Foo $instance): Foo > { > $instance->bar = $bar; // Allowed as we're in scope > return $instance; > } > } > > Only operations in the scope of the class itself (and it's descendants, > adhering to standard visibility rules) can make changes on the cloned > variant. The `with ($instance)` is optional, $instance is just a variable > name. In reality you'll want to use it most of the time I imagine. > > I suppose you can re-use the `use` keyword here too. > > Also, this shouldn't allow for immutable properties. > > Another option is to look at the way that HHVM does immutable types, > though that is _file_ based. > > - Davey > > > -- Silvio Marijić Software Engineer 2e Systems --- ## #97365 — Rowan Collins — 2016-12-12T14:14:26+00:00 URL: https://externals.io/message/97355#97365 · In reply to: #97364 >Regarding my proposal above, since `copy()` would essentially operate >only on >immutable objects, why not put it only there. So you would be able to >make >a call like this one $immutable->copy(array $args); or >$this->copy(array >$args); depending on whether you are inside let's say with* method or >outside of the object. If users of the object can set arbitrary (public) properties this way, then you've thrown away a bunch of the free encapsulation the immutable keyword gave you in the first place. What you get is an enforced copy-on-write, where you can set the properties to whatever state you like, just not using normal object passing semantics. That's very different from what the RFC shows, which are properties which are publicly readable, but whose state is exclusively controlled by the class (and its descendants). PS The rule on this mailing list is too always reply *below* the text you're replying to. -- Rowan Collins [IMSoP] --- ## #97366 — marijic.silvio@gmail.com — 2016-12-12T14:42:11+00:00 URL: https://externals.io/message/97355#97366 · In reply to: #97365 2016-12-12 15:14 GMT+01:00 Rowan Collins : > On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" < > marijic.silvio@gmail.com> wrote: > > […] > > If users of the object can set arbitrary (public) properties this way, > then you've thrown away a bunch of the free encapsulation the immutable > keyword gave you in the first place. What you get is an enforced > copy-on-write, where you can set the properties to whatever state you like, > just not using normal object passing semantics. That's very different from > what the RFC shows, which are properties which are publicly readable, but > whose state is exclusively controlled by the class (and its descendants). > > > PS The rule on this mailing list is too always reply *below* the text > you're replying to. > -- > Rowan Collins > [IMSoP] > > -- > > > > I understand that, but I think we'll have to meet in the middle. How would you handle situation where for one little change you have to manually recreate not so trivial object with a lot of arguments ? I don't think that should be a deal breaker for this RFC but I do agree that we should try to find solution to bridge that gap and put that aside in a other rfc. -- Silvio Marijić Software Engineer 2e Systems --- ## #97367 — marijic.silvio@gmail.com — 2016-12-12T14:43:24+00:00 URL: https://externals.io/message/97355#97367 · In reply to: #97365 2016-12-12 15:14 GMT+01:00 Rowan Collins : > On 12 December 2016 09:11:17 GMT+00:00, "Silvio Marijić" < > marijic.silvio@gmail.com> wrote: > > […] > > If users of the object can set arbitrary (public) properties this way, > then you've thrown away a bunch of the free encapsulation the immutable > keyword gave you in the first place. What you get is an enforced > copy-on-write, where you can set the properties to whatever state you like, > just not using normal object passing semantics. That's very different from > what the RFC shows, which are properties which are publicly readable, but > whose state is exclusively controlled by the class (and its descendants). > > > PS The rule on this mailing list is too always reply *below* the text > you're replying to. > I understand that, but I think we'll have to meet in the middle. How would > you handle situation where for one little change you have to manually > recreate not so trivial object with a lot of arguments ? I don't think that > should be a deal breaker for this RFC but I do agree that we should try to > find solution to bridge that gap and put that aside in a other rfc. > -- > Rowan Collins > [IMSoP] > > -- > > > > -- Silvio Marijić Software Engineer 2e Systems --- ## #97374 — marijic.silvio@gmail.com — 2016-12-12T18:06:09+00:00 URL: https://externals.io/message/97355#97374 · In reply to: #97367 Hi, this would be basic implementation of 'modify' function which would operate on cloned object PHP_FUNCTION(modify) { zval *obj, *properties, *entry; zend_long h; zend_string *key; if (zend_parse_parameters(ZEND_NUM_ARGS(), "oa", &obj, &properties) == FAILURE) { return; } ZEND_HASH_FOREACH_KEY_VAL_IND(Z_ARRVAL_P(properties), h, key, entry) { zval member; ZVAL_STR(&member, key); zend_std_write_property(obj, &member, entry, NULL); zval_ptr_dtor(&member); } ZEND_HASH_FOREACH_END(); RETVAL_OBJ(Z_OBJ_P(obj)); } immutable class User{ public $firstname; public $lastname; public function __construct($firstname, $lastname){} public function withFirstName($firstname){ return modify($this, ['firstname' => $firstname]); } } $user = new User('John', 'Doe'); $new = $user->withFirstName('Foo'); Any feedback? 2016-12-12 15:43 GMT+01:00 Silvio Marijić : > > > 2016-12-12 15:14 GMT+01:00 Rowan Collins : > > > […] > > > > > […] > -- > > […] > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- Silvio Marijić Software Engineer 2e Systems --- ## #97375 — Fleshgrinder — 2016-12-12T18:44:39+00:00 URL: https://externals.io/message/97355#97375 · In reply to: #97355 > Hi, > > Discussion is open for following rfc https://wiki.php.net/rfc/immutability > > Cheers > -1 from my side for all the things previously mentioned. The copy-on-write topic must be solved along with the introduction of immutable classes or we end up with this being implemented and not way to mutate them in a controlled fashion. Also -1 on the proposed `copy` or `modify` function. Not only does it seem to allow anyone to mutate the immutable object, it also requires magic strings of the property names. No usage search, no refactoring, no ... I still strongly believe that `__clone` should be made `private` or `protected` for immutable classes to avoid useless cloning. After that we either stick to cloning as we currently do in our `with*` methods or we provide a keyword that changes the behavior of a method. I also propose to use `data` or `value` instead of `immutable` as the class modifier keyword. Its shorter and properly as well as fully communicates what kind of object we are building. -- Richard "Fleshgrinder" Fussenegger --- ## #97376 — marijic.silvio@gmail.com — 2016-12-12T19:19:50+00:00 URL: https://externals.io/message/97355#97376 · In reply to: #97375 @Fleshgrinder My opinion on that subject is still that features are mostly complete but I'am willing to find also solution to ease modifying. Modify function does not modify object in any way, it will operate on the clone of the object and this was just prototype. Moreover it should be restricted to be only callable from the scope of the object. Introducing method modifier causes more problems then it solves, and has whole another level of complexity. Regarding changing keyword, 'data' does not fit because object is behaviour + data, with behaviour beeing (or at least it should be) at the first place. Value can imply or create confusion with Value Objects, on the other hand immutable clearly states what it is. Cheers, 2016-12-12 19:44 GMT+01:00 Fleshgrinder : > > > […] > immutability > > […] > > -1 from my side for all the things previously mentioned. The > copy-on-write topic must be solved along with the introduction of > immutable classes or we end up with this being implemented and not way > to mutate them in a controlled fashion. > > Also -1 on the proposed `copy` or `modify` function. Not only does it > seem to allow anyone to mutate the immutable object, it also requires > magic strings of the property names. No usage search, no refactoring, no > ... > > I still strongly believe that `__clone` should be made `private` or > `protected` for immutable classes to avoid useless cloning. After that > we either stick to cloning as we currently do in our `with*` methods or > we provide a keyword that changes the behavior of a method. > > I also propose to use `data` or `value` instead of `immutable` as the > class modifier keyword. Its shorter and properly as well as fully > communicates what kind of object we are building. > > -- > Richard "Fleshgrinder" Fussenegger > -- Silvio Marijić Software Engineer 2e Systems --- ## #97377 — Rowan Collins — 2016-12-12T19:25:50+00:00 URL: https://externals.io/message/97355#97377 · In reply to: #97366 >I understand that, but I think we'll have to meet in the middle. How >would >you handle situation where for one little change you have to manually >recreate not so trivial object with a lot of arguments ? I don't think >that >should be a deal breaker for this RFC but I do agree that we should try >to >find solution to bridge that gap and put that aside in a other rfc. I think there needs to be some "escape hatch" that the author of the class itself can use and control. For instance, a keyword on methods that marks them as a kind of copy constructor, giving them the same abilities as __construct has. Regards, -- Rowan Collins [IMSoP] --- ## #97378 — Fleshgrinder — 2016-12-12T19:29:18+00:00 URL: https://externals.io/message/97355#97378 · In reply to: #97376 > @Fleshgrinder > > My opinion on that subject is still that features are mostly complete but > I'am willing to find also solution to ease modifying. > Modify function does not modify object in any way, it will operate on the > clone of the object and this was just prototype. Moreover it should be > restricted to be only callable from the scope of the object. Introducing > method modifier causes more problems then it solves, and has whole another > level of complexity. Regarding changing keyword, 'data' does not fit > because object is behaviour + data, with behaviour beeing (or at least it > should be) at the first place. Value can imply or create confusion with > Value Objects, on the other hand immutable clearly states what it is. > > Cheers, > The term data class comes from data transfer object (DTO). Uncle Bob uses the term extensively in his books. https://sourcemaking.com/refactoring/smells/data-class https://kotlinlang.org/docs/reference/data-classes.html https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idas200/underdc.htm So it would be rather `$this->modify()` or `$this->copy()` and not simply `modify()` nor `copy()`. ;) The problem persists that you end up with lots of magic strings ... :( -- Richard "Fleshgrinder" Fussenegger --- ## #97379 — Andrea Faulds — 2016-12-12T19:36:47+00:00 URL: https://externals.io/message/97355#97379 · In reply to: #97355 Hi Silvio, Silvio Marijić wrote: >Discussion is open for following rfc https://wiki.php.net/rfc/immutability The restriction that immutable properties may only hold immutable values seems potentially overzealous. Consider that not all immutable classes will actually be marked as such. Any code written in, say, PHP 7.2 if it included this feature, would not be able to make an immutable property if it pointed to an immutable object made before PHP 7.2 which couldn't use this feature. Another consideration is that your existing restrictions (only objects of immutable classes and resources) are not restrictive enough to achieve the desired end of enforcing deep immutability. Arrays can contain object values, as well as array values which might themselves contain values that are objects. They also can contain references. In order to enforce that immutable properties do not point to anything mutable, you would have to search any given array for mutable values, including sub-arrays. You would need to make sure you check for recusion here, lest assigning to an immutable property potentially crash the interpreter. This could be a significant runtime cost, it's at least an O(n) operation. I think that, realistically, trying to enforce immutability of values in an immutable class is not worth it, and makes the feature less useful. Consider that some popular applications of immutability ultimately contain a reference to something mutable: PSR-7's immutable HTTP message objects point to mutable streams, and Docker's immutable containers point to mutable volumes. Thanks. -- Andrea Faulds https://ajf.me/ --- ## #97380 — Paul Jones — 2016-12-12T19:56:08+00:00 URL: https://externals.io/message/97355#97380 · In reply to: #97379 > > > Consider that some popular applications of immutability ultimately contain a reference to something mutable: PSR-7's immutable HTTP message objects point to mutable streams Which subverts its overall promise of immutability (and the streams are not the only place where the promise of immutability is subverted). -- Paul M. Jones pmjones88@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php --- ## #97381 — marijic.silvio@gmail.com — 2016-12-13T09:17:06+00:00 URL: https://externals.io/message/97355#97381 · In reply to: #97380 After much thinking regarding array in immutable objects I'm thinking of revoking this RFC. If someone has some suggestion on that matter now is the time, but otherwise my work is done on this one. Cheers, 2016-12-12 20:56 GMT+01:00 Paul Jones : > > > […] > contain a reference to something mutable: PSR-7's immutable HTTP message > objects point to mutable streams > > Which subverts its overall promise of immutability (and the streams are > not the only place where the promise of immutability is subverted). > > > -- > Paul M. Jones > pmjones88@gmail.com > http://paul-m-jones.com > > Modernizing Legacy Applications in PHP > https://leanpub.com/mlaphp > > Solving the N+1 Problem in PHP > https://leanpub.com/sn1php > > > > > -- > > > > -- Silvio Marijić Software Engineer 2e Systems --- ## #97382 — Markus Fischer — 2016-12-13T10:24:18+00:00 URL: https://externals.io/message/97355#97382 · In reply to: #97381 Hello, > After much thinking regarding array in immutable objects I'm thinking of > revoking this RFC. If someone has some suggestion on that matter now is the > time, but otherwise my work is done on this one. It would be nice if you could summarize the feedback into the RFC too (i.e. the "Cons" points), maybe someone wants to pick it up later or learn from it. And thanks for the effort! - Markus --- ## #97402 — Andrea Faulds — 2016-12-14T16:43:52+00:00 URL: https://externals.io/message/97355#97402 · In reply to: #97380 Hi, Paul Jones wrote: > > > […] > > Which subverts its overall promise of immutability (and the streams are not the only place where the promise of immutability is subverted). Indeed. It's not necessarily a good feature, don't get me wrong. -- Andrea Faulds https://ajf.me/ --- ## #97795 — Stanislav Malyshev — 2017-01-16T21:38:35+00:00 URL: https://externals.io/message/97355#97795 · In reply to: #97355 Hi! > Discussion is open for following rfc https://wiki.php.net/rfc/immutability The RFC says: > Safe for concurrency. I'm not sure - what concurrency are you talking about? > Value objects, DTO's etc. can be easily created. Value objects can be easily created right now if you follow generic best practices - private properties and no setters, here you go with value object. > Properties can be public which removes need for getters without allowing state modification. Not sure why it is a good thing to have public properties? Also, not sure how you are going to resolve references to such properties. -- Stas Malyshev smalyshev@gmail.com --- ## #97801 — Yasuo Ohgaki — 2017-01-17T09:12:30+00:00 URL: https://externals.io/message/97355#97801 · In reply to: #97381 Hi Silvio, On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić wrote: > After much thinking regarding array in immutable objects I'm thinking of > revoking this RFC. If someone has some suggestion on that matter now is the > time, but otherwise my work is done on this one. > It may be good to start from constant scalars. ES6 has "let" and "const". PHP has "const", but PHP's constant does not have scope other than class. It would be nice if const can be used like JS. e.g. Following is syntax error. It would be large enough changes for 8.0, though. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #97803 — marijic.silvio@gmail.com — 2017-01-17T09:33:09+00:00 URL: https://externals.io/message/97355#97803 · In reply to: #97801 Hi Yasuo, Yes, that looks like interesting idea. I can open another RFC and start working on that one, if there is a interest for that. Why can't we fit that into 7.2 ? Cheers, 2017-01-17 10:12 GMT+01:00 Yasuo Ohgaki : > Hi Silvio, > > On Tue, Dec 13, 2016 at 6:17 PM, Silvio Marijić > wrote: > > > […] > > It may be good to start from constant scalars. > ES6 has "let" and "const". PHP has "const", but PHP's constant does not > have scope other than class. It would be nice if const can be used like JS. > > e.g. Following is syntax error. > function foo($v) { > const v=$v; > // Some complex code here. > return v * $var; > } > > var_dump(foo(123)); > ?> > > It would be large enough changes for 8.0, though. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > -- Silvio Marijić Software Engineer 2e Systems