# RFC - Immutable classes - Thread: https://externals.io/message/94913 - Original archive: https://news-web.php.net/php.internals/94913 - Started by marijic.silvio@gmail.com on 2016-08-08T10:31:03+00:00 - Messages: 82 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/94913.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 --- ## #94913 — marijic.silvio@gmail.com — 2016-08-08T10:31:03+00:00 URL: https://externals.io/message/94913#94913 Hi, I would need your help with one idea. I'm working on one RFC that I'm would like to submit. Idea is that after you initialize object eg. after constructor returns, object would be locked, and you wouldn't be able to change properties on that object anymore. It would like this: public $email; > public function __construct($email){ > $this->email = $email; > } > } > $email = new Email("example@email.com"); After instance of class is created, object is "frozen" so call like this $email->email = "new@email.com"; Would result in error. I have already implementation up to certain degree, but I need one advice from more experienced developers. Where is the place where I could put logic to lock object after the constructor has finished? Maybe in zend vm on ZEND_NEW token? Some constraints are needed: 1. Child class that extends immutable class must be defined as immutable also. 2. If property on immutable class contains object, it must be instance of immutable class. 3. You can not have immutability per property, it either whole class or none. Thank you all in advance. -- Silvio Marijić Software Engineer 2e Systems --- ## #94917 — michal@brzuchalski.com — 2016-08-08T11:16:26+00:00 URL: https://externals.io/message/94913#94917 · In reply to: #94913 Hi Silvio, Look into my talk about final properties https://marc.info/? t=145979255800003&r=1&w=2 maybe there would be something usefull. There is also talk about mutable and immutable properties and other class modifiers also about var and val. I'm not sure that it should be class midifier rather than proprty modifier keyword. regards, -- Michał Brzuchalski 2016-08-08 12:31 GMT+02:00 Silvio Marijić : > Hi, > > I would need your help with one idea. I'm working on one RFC that I'm would > like to submit. Idea is that after you initialize object eg. after > constructor returns, object would be locked, and you wouldn't be able to > change properties on that object anymore. It would like this: > > > immutable class Email { > > […] > > > > After instance of class is created, object is "frozen" so call like this > > $email->email = "new@email.com"; > > > Would result in error. > > I have already implementation up to certain degree, but I need one advice > from more experienced developers. Where is the place where I could put > logic to lock object after the constructor has finished? Maybe in zend vm > on ZEND_NEW token? > > Some constraints are needed: > > 1. Child class that extends immutable class must be defined as immutable > also. > 2. If property on immutable class contains object, it must be instance > of immutable class. > 3. You can not have immutability per property, it either whole class or > none. > > Thank you all in advance. > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski --- ## #94920 — marijic.silvio@gmail.com — 2016-08-08T12:31:15+00:00 URL: https://externals.io/message/94913#94920 · In reply to: #94917 I see your standpoint, but I think it could cause confusion because of final classes. I think "immutable" is more suited here. What I try to achieve is something similar like case classes in Scala. Best regards, 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski : > Hi Silvio, > > Look into my talk about final properties https://marc.info/? > t=145979255800003&r=1&w=2 maybe there would be something usefull. > There is also talk about mutable and immutable properties and other class > modifiers also about var and val. > I'm not sure that it should be class midifier rather than proprty modifier > keyword. > > regards, > -- > Michał Brzuchalski > > 2016-08-08 12:31 GMT+02:00 Silvio Marijić : > > > […] > > > > -- > pozdrawiam > -- > Michał Brzuchalski > -- Silvio Marijić Software Engineer 2e Systems --- ## #94921 — marijic.silvio@gmail.com — 2016-08-08T12:46:01+00:00 URL: https://externals.io/message/94913#94921 · In reply to: #94920 Btw, I was not aware that there was already conversation on immutable classes. 2016-08-08 14:31 GMT+02:00 Silvio Marijić : > I see your standpoint, but I think it could cause confusion because of > final classes. I think "immutable" is more suited here. > What I try to achieve is something similar like case classes in Scala. > > Best regards, > > 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski : > > > […] > > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- Silvio Marijić Software Engineer 2e Systems --- ## #94922 — michal@brzuchalski.com — 2016-08-08T12:47:13+00:00 URL: https://externals.io/message/94913#94922 · In reply to: #94921 Sure my final properties was first thought, lately in discuccion it turns into immutable, sealed and final see here https://marc.info/?l=php-internals&m=146005058530881&w=2 Have you also read about Immutable modifier from last year? http://marc.info/?t=144766539400001&r=1&w=2 it's exactly about immutable classes! 2016-08-08 14:46 GMT+02:00 Silvio Marijić : > Btw, I was not aware that there was already conversation on immutable > classes. > > 2016-08-08 14:31 GMT+02:00 Silvio Marijić : > > > […] > > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski --- ## #94923 — S.A.N — 2016-08-08T12:47:56+00:00 URL: https://externals.io/message/94913#94923 · In reply to: #94920 May be better to do as immutable arrays? const = new Email; it will be a super global immutable instance of Email. --- ## #94924 — S.A.N — 2016-08-08T12:48:50+00:00 URL: https://externals.io/message/94913#94924 · In reply to: #94923 May be better to do as immutable arrays? const EmailObject = new Email; It will be a super global immutable instance of Email. --- ## #94925 — michal@brzuchalski.com — 2016-08-08T12:49:52+00:00 URL: https://externals.io/message/94913#94925 · In reply to: #94923 2016-08-08 14:47 GMT+02:00 S.A.N : > May be better to do as immutable arrays? > > const = new Email; > > it will be a super global immutable instance of Email. > I think you've missunderstood concept of immutable classes. -- pozdrawiam -- Michał Brzuchalski --- ## #94926 — marijic.silvio@gmail.com — 2016-08-08T13:00:12+00:00 URL: https://externals.io/message/94913#94926 · In reply to: #94925 @Michal, well no I did read it. I see that there is not much going on there since last year. Did you tried to implement it ? 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski : > > 2016-08-08 14:47 GMT+02:00 S.A.N : > > > […] > > I think you've missunderstood concept of immutable classes. > > > -- > pozdrawiam > -- > Michał Brzuchalski > -- Silvio Marijić Software Engineer 2e Systems --- ## #94927 — michal@brzuchalski.com — 2016-08-08T13:20:28+00:00 URL: https://externals.io/message/94913#94927 · In reply to: #94926 @Silvio I've tried to implement final https://github.com/php/php-src/compare/master...brzuchal:final-properties but haven't found time to implement immutable and sealed, AFAIK I had problems with OPcache enabled, you need to remember to run every test after compile with opcache enabled in CLI. 2016-08-08 15:00 GMT+02:00 Silvio Marijić : > @Michal, well no I did read it. I see that there is not much going on > there since last year. Did you tried to implement it ? > > 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski : > > > […] > > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski --- ## #94928 — marijic.silvio@gmail.com — 2016-08-08T13:23:57+00:00 URL: https://externals.io/message/94913#94928 · In reply to: #94927 @Michal Would you consider cooperating on implementing immutable and sealed modifiers? 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski : > @Silvio I've tried to implement final https://github.com/php/ > php-src/compare/master...brzuchal:final-properties but haven't found time > to implement immutable and sealed, AFAIK I had problems with OPcache > enabled, you need to remember to run every test after compile with opcache > enabled in CLI. > > 2016-08-08 15:00 GMT+02:00 Silvio Marijić : > > > […] > > > > -- > pozdrawiam > -- > Michał Brzuchalski > -- Silvio Marijić Software Engineer 2e Systems --- ## #94929 — michal@brzuchalski.com — 2016-08-08T13:51:23+00:00 URL: https://externals.io/message/94913#94929 · In reply to: #94928 It is great to hear somone is interested so why not. My lately discussion found usefull implementing 3 keywords, such as: 1. *immutable* for the functionality you are currently working on. 2. *sealed* for the above plus type not changeable. 3. *final* for the above plus not being overridable. But all of them should be implemented in different RFC's starting from Immutable because it's base point to toher two keywords. Whole idea needs refreshing discussion to clarify idea so it can success. 2016-08-08 15:23 GMT+02:00 Silvio Marijić : > @Michal Would you consider cooperating on implementing immutable and > sealed modifiers? > > 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski : > > > […] > > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski --- ## #94932 — marijic.silvio@gmail.com — 2016-08-08T15:00:24+00:00 URL: https://externals.io/message/94913#94932 · In reply to: #94929 It's great that you are up of this. I think it will be great to see this one in action. I agree that we should separate them into separate RFC-s. 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski : > It is great to hear somone is interested so why not. My lately discussion > found usefull implementing 3 keywords, such as: > 1. *immutable* for the functionality you are currently working on. > 2. *sealed* for the above plus type not changeable. > 3. *final* for the above plus not being overridable. > > But all of them should be implemented in different RFC's starting from > Immutable because it's base point to toher two keywords. > Whole idea needs refreshing discussion to clarify idea so it can success. > > 2016-08-08 15:23 GMT+02:00 Silvio Marijić : > > > […] > > > > -- > pozdrawiam > -- > Michał Brzuchalski > -- Silvio Marijić Software Engineer 2e Systems --- ## #94938 — Fleshgrinder — 2016-08-08T16:44:00+00:00 URL: https://externals.io/message/94913#94938 · In reply to: #94932 > It's great that you are up of this. > I think it will be great to see this one in action. > > I agree that we should separate them into separate RFC-s. > > 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski : > > > […] I would like to offer my support. I might not be as familiar as you guys with the C source but if you need anything (e.g. documentation, RFC writing, testing, ...) let me know. -- Richard "Fleshgrinder" Fussenegger --- ## #94943 — marijic.silvio@gmail.com — 2016-08-08T17:16:33+00:00 URL: https://externals.io/message/94913#94943 · In reply to: #94938 @Fleshgrinder, Thanks, every help is welcome. 2016-08-08 18:44 GMT+02:00 Fleshgrinder : > > > […] > discussion > > […] > success. > > […] > > I would like to offer my support. I might not be as familiar as you guys > with the C source but if you need anything (e.g. documentation, RFC > writing, testing, ...) let me know. > > -- > Richard "Fleshgrinder" Fussenegger > > -- Silvio Marijić Software Engineer 2e Systems --- ## #94945 — michal@brzuchalski.com — 2016-08-08T17:19:14+00:00 URL: https://externals.io/message/94913#94945 · In reply to: #94943 @Fleshgrinder thanks, my knowledge of C allowed me to implement some features experimentally. When problem occurs then I'll find any needed help because I think this feature is needed. Personally I don't have wiki karma so help in writing RFC if you have karma could help us very much. 2016-08-08 19:16 GMT+02:00 Silvio Marijić : > @Fleshgrinder, Thanks, every help is welcome. > > 2016-08-08 18:44 GMT+02:00 Fleshgrinder : > > > […] > > > -- > Silvio Marijić > Software Engineer > 2e Systems > -- pozdrawiam -- Michał Brzuchalski --- ## #95538 — marijic.silvio@gmail.com — 2016-09-01T13:49:07+00:00 URL: https://externals.io/message/94913#95538 Hi Andre, Here is RFC https://wiki.php.net/rfc/immutability and you have link to implementation github. Any suggestions and feedback are more then welcome. Best, Silvio 2016-09-01 15:43 GMT+02:00 André Rømcke : > > > > […] > wrote: > > […] > karma > > […] > > > I would also like to contribute to help make this RFC happen, anything > that needs help on in terms of doc or rfc wiki? > > > Best, > André (andrerom) -- Silvio Marijić Software Engineer 2e Systems --- ## #95544 — Fleshgrinder — 2016-09-01T19:12:51+00:00 URL: https://externals.io/message/94913#95544 · In reply to: #95538 > Hi Andre, > > Here is RFC https://wiki.php.net/rfc/immutability and you have link to > implementation github. Any suggestions and feedback are more then welcome. > > Best, > Silvio > Hi Silvio, very nice work you guys did here! :) Abstract classes are not mentioned at all in the RFC. However, there is a test case from which it is clear that abstract classes cannot be immutable. Are there any reasons for this restrictions? What about array and resource values? Not mentioned in the RFC. The fact that cloning is not possible should also be extended in the RFC. I mean, it's clear to me but maybe not to others. Remember that the RFC is the main source of information for the feature (e.g. to generate documentation). Why the restrictions that all properties of an immutable class that take objects must be immutable too? It's clear why an immutable property must contain an immutable class but the inheritance from the class to the properties is not consistent with how things work. An immutable class might want to contain an internal cache (e.g. flyweight pattern). immutable final class Flyweight { private static $instances = []; public immutable $value; private function __construct($value) { $this->value = $value; } public static function ENUM_ORD() { if (isset(self::$instances[1]) === false) { self::$instances[1] = new self(1); } return self::$instances[1]; } } $o1 = Flyweight::ENUM_ORD(); $o2 = Flyweight::ENUM_ORD(); var_dump($o1 === $o2); // bool(true) Note that we could add the restriction that an immutable class that should be used in a threading context must contain only immutable properties in the future when the need arises. However, for now I do not see the need to inherit the modifier from the class to its properties and I see use cases where the developer wants more control. The test cases cover the most stuff but not everything and could be extended. There are other things with the PR but I will check it out and create a PR against your branch with that so you can review it. (Might take a while so bare with me.) The RFC contains several grammatical issues. I could help you with that too if you want. There is a lot of diff noise in the ext/tokenizer/tokenizer_data.c file. -- Richard "Fleshgrinder" Fussenegger --- ## #95547 — Mathieu Rochette — 2016-09-01T21:48:43+00:00 URL: https://externals.io/message/94913#95547 · In reply to: #95544 > > > […] > Hi Silvio, > > very nice work you guys did here! :) indeed! nice to see this going forward > > Abstract classes are not mentioned at all in the RFC. However, there is > a test case from which it is clear that abstract classes cannot be > immutable. Are there any reasons for this restrictions? > > What about array and resource values? Not mentioned in the RFC. I guess they are not authorized in immutable classes as they are not immutable themselves, but I think it could be explained > > The fact that cloning is not possible should also be extended in the > RFC. I mean, it's clear to me but maybe not to others. Remember that the > RFC is the main source of information for the feature (e.g. to generate > documentation). agreed, I don't get why it's not possible :/ > > Why the restrictions that all properties of an immutable class that take > objects must be immutable too? It's clear why an immutable property must > contain an immutable class but the inheritance from the class to the > properties is not consistent with how things work. An immutable class > might want to contain an internal cache (e.g. flyweight pattern). > > immutable final class Flyweight { > > private static $instances = []; > > public immutable $value; > > private function __construct($value) { > $this->value = $value; > } > > public static function ENUM_ORD() { > if (isset(self::$instances[1]) === false) { > self::$instances[1] = new self(1); > } > > return self::$instances[1]; > } > > } > > $o1 = Flyweight::ENUM_ORD(); > $o2 = Flyweight::ENUM_ORD(); > > var_dump($o1 === $o2); // bool(true) I can understand the usecase, but then, how could the language ensure the class is immutable side note: what about access (read & write) to undefined properties ? > > Note that we could add the restriction that an immutable class that > should be used in a threading context must contain only immutable > properties in the future when the need arises. However, for now I do not > see the need to inherit the modifier from the class to its properties > and I see use cases where the developer wants more control. > > The test cases cover the most stuff but not everything and could be > extended. There are other things with the PR but I will check it out and > create a PR against your branch with that so you can review it. (Might > take a while so bare with me.) > > The RFC contains several grammatical issues. I could help you with that > too if you want. > > There is a lot of diff noise in the ext/tokenizer/tokenizer_data.c file. > -- Mathieu Rochette --- ## #95549 — michal@brzuchalski.com — 2016-09-02T02:23:32+00:00 URL: https://externals.io/message/94913#95549 · In reply to: #95547 Firstly, thanks for your interest. My answers are inline. 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > > > > > […] > welcome. > > […] > indeed! nice to see this going forward > > […] > I guess they are not authorized in immutable classes as they are not > immutable themselves, but I think it could be explained > Yes that could be explained, they are actually not authorized because we cannot guarantee developer will use them internally only. So in case this property will interact with immutable object state should be also immutable. > > […] > agreed, I don't get why it's not possible :/ > > […] > I think any RFC enchancements in this area is welcome. > > […] > I can understand the usecase, but then, how could the language ensure > the class is immutable It cannot be ensured while non-immutable property will exists in immutable object. > side note: what about access (read & write) to undefined properties ? > You mean properties which are declared and default null and never changed during object instantiation? > > […] > We agreed that it would be best for ensuring the object state is immutable (that implies it can be deeply frozen for writes as deep as all his properties and properties object properties etc.) > > […] > > The RFC contains several grammatical issues. I could help you with that > > […] > As abowe any RFC enchancements are welcome :) > > […] > > -- > Mathieu Rochette > > > -- > > > > -- regards / pozdrawiam, -- Michał Brzuchalski brzuchalski.com --- ## #95552 — marijic.silvio@gmail.com — 2016-09-02T07:10:17+00:00 URL: https://externals.io/message/94913#95552 · In reply to: #95549 Hi Fleshgrinder, Since Michal answered most of the questions, I'll just add some notes. Initially I added restrictions to abstract classes, but I did think about that over the last couple of days and couldn't find any concrete reason for that restriction, so I think I'm going to remove that. As far as cloning, it is disabled for immutable objects, because you'll end up with the copy of object that you can not modify. I did mention in Cons sections that cloning is disabled, maybe it should be made more clear. Best, Silvio. 2016-09-02 4:23 GMT+02:00 Michał Brzuchalski : > Firstly, thanks for your interest. > My answers are inline. > > 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > > > […] > to > > […] > > Yes that could be explained, they are actually not authorized because we > cannot guarantee developer will use them internally only. So in case this > property will interact with immutable object state should be also > immutable. > > > > […] > the > > […] > > I think any RFC enchancements in this area is welcome. > > > > […] > take > > […] > must > > […] > > > It cannot be ensured while non-immutable property will exists in immutable > object. > > > > […] > > You mean properties which are declared and default null and never changed > during object instantiation? > > > > […] > not > > […] > > We agreed that it would be best for ensuring the object state is immutable > (that implies it can be deeply frozen for writes as deep as all his > properties > and properties object properties etc.) > > > > […] > and > > […] > > As abowe any RFC enchancements are welcome :) > > > > […] > file. > > […] > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > brzuchalski.com > -- Silvio Marijić Software Engineer 2e Systems --- ## #95554 — Mathieu Rochette — 2016-09-02T09:06:01+00:00 URL: https://externals.io/message/94913#95554 · In reply to: #95549 thank you for the clarification, more questions inline :) > Firstly, thanks for your interest. > My answers are inline. > > 2016-09-01 23:48 GMT+02:00 Mathieu Rochette : > > > […] > Yes that could be explained, they are actually not authorized because we > cannot guarantee developer will use them internally only. So in case this > property will interact with immutable object state should be also immutable. > > > > […] > I think any RFC enchancements in this area is welcome. > > > > […] > > It cannot be ensured while non-immutable property will exists in immutable > object. > > > > […] > You mean properties which are declared and default null and never changed > during object instantiation? I meant properties which are not declared at all, eg: class foo { } $f = new foo(); var_dump($f->bar); $f->bar = 'taz'; I expect it to print null and throw an error on write access, but it's just to be sure. actually I guest it should be the same than with declared with default null and never changed during object instantiation > > > > […] > We agreed that it would be best for ensuring the object state is immutable > (that implies it can be deeply frozen for writes as deep as all his > properties > and properties object properties etc.) > > > > […] > As abowe any RFC enchancements are welcome :) > > > > […] > -- Mathieu Rochette --- ## #95555 — marijic.silvio@gmail.com — 2016-09-02T09:22:49+00:00 URL: https://externals.io/message/94913#95555 · In reply to: #95554 From point of immutability of object, there is no difference if property is defined or not, so you are correct, last line in your code will throw an error. 2016-09-02 11:06 GMT+02:00 Mathieu Rochette : > thank you for the clarification, more questions inline :) > > > > > […] > to > > […] > immutable. > > […] > the > > […] > take > > […] > must > > […] > immutable > > […] > I meant properties which are not declared at all, eg: > > class foo { > } > $f = new foo(); > var_dump($f->bar); > $f->bar = 'taz'; > > I expect it to print null and throw an error on write access, but it's > just to be sure. actually I guest it should be the same than with > declared with default null and never changed during object instantiation > > > […] > not > > […] > immutable > > […] > and > > […] > file. > > […] > > -- > Mathieu Rochette > > > -- > > > > -- Silvio Marijić Software Engineer 2e Systems --- ## #95564 — marijic.silvio@gmail.com — 2016-09-02T14:06:04+00:00 URL: https://externals.io/message/94913#95564 Well at the moment expection is thrown in case when you try to clone immutable object. But you do seem to have valid point there regarding __clone method. I'm definitely going to give it a thought. Best, Silvio. 2016-09-02 15:52 GMT+02:00 André Rømcke : > > > > […] > wrote: > > […] > for > > […] > > > _If_ there are use-cases for it, wouldn’t it also be safe that the clone > is allowed to be modified during __clone() and afterwards sealed? Like in > __construct(). > And if you don’t want to allow cloning, throw in __clone. > > Best, > André > > > > […] > is > > […] > this > > […] > generate > > […] > immutable > > […] > changed > > […] > immutable > > […] > > -- Silvio Marijić Software Engineer 2e Systems --- ## #95566 — Larry Garfield — 2016-09-02T14:27:47+00:00 URL: https://externals.io/message/94913#95566 · In reply to: #95564 > Well at the moment expection is thrown in case when you try to clone > immutable object. But you do seem to have valid point there regarding > __clone method. I'm definitely going to give it a thought. > > Best, > Silvio. > > 2016-09-02 15:52 GMT+02:00 André Rømcke : > > > […] I'd have to agree here. I love the idea of "lockable" immutable objects. However, the __clone() method has to be a modifiable area just like __construct() or else it's effectively useless for anything more than a trivial object. This was one of the main concerns with immutability in the PSR-7 discussions. Consider this sample class, with 8 properties (entirely reasonable for a complex value object): immutable class Record { public $a; public $b; public $c; public $d; public $e; public $f; public $g; public $h; public function __construct($a, $b, $c, $d, $e, $f, $g, $h) { $this->a = $a; $this->b = $b; $this->c = $c; $this->d = $d; $this->e = $e; $this->f = $f; $this->g = $g; $this->h = $h; } } Now I want a new value object that is the same, except that $d is incremented by 2. That is, I'm building up the value object over time rather than knowing everything at construct time. (This is exactly the use case of PSR-7.) I have to do this: $r1 = new Record(1, 2, 3, 4, 5, 6, 7, 8); $r2 - new Record($r1->a, $r1->b, $r1->c, $r1->d + 2, $1->e, $r1->f, $r1->g, $r1->h); That's crazy clunky, and makes immutable objects not very useful. Imagine a money object where you had to dissect it to its primitives, tweak one, and then repackage it just to add a dollar figure to it. That's not worth the benefit of being immutable. The way PSR-7 addressed that (using fake-immutability, basically), was this: class Response { // ... protected $statusCode; public function withStatusCode($code) { $new = clone($this); $new->statusCode = $code; return $new; } } That is, outside of the object there's no way to modify it in place, but it becomes super easy to get a slightly-modified version of the object: $r2 = $r1->withStatusCode(418); And because of PHP's copy-on-write support, it's actually surprisingly cheap. For language-level immutable objects, we would need some equivalent of that behavior. I'm not sure exactly what form it should take (explicit lock/unlock commands is all I can think of off hand, which I dislike), but that's the use case that would need to be addressed. --Larry Garfield --- Next page: https://externals.io/message/94913.md?page=2