<div dir="ltr">Hi All,<div><br></div><div>    we're moving close to a new Squeak release.  There are some issues to discuss before we decide  exactly what and when to release.  I have two issues that I would like people's opinions on.</div><div><br></div><div>1. the VM can be compiled with support for read-only objects, and indeed Pharo is already doing this.  Were we to enable read-only object support we could introduce read-only bindings.  I have this code ready to go, but the current Squeak VM does not include read-only object support.  We could go ahead and release without read-only object support or enable read-only object support in the VM, push the new VMs out and enable read-only literals.  It would then take a few days for everyone to test their code and fix issues with read-only literals.  For example, code such as</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre">    </span>a := { 'one ' . 'two ' . 'three ' }.</div><div><span class="gmail-Apple-tab-span" style="white-space:pre">   </span>a do: [:e | e at: e size put: (Character value: 0)].</div></div><div><br></div><div>must be rewritten, e.g. as</div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"><br></span></div><div><span class="gmail-Apple-tab-span" style="white-space:pre">       </span>a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll: Character space asString with: Character null asString].</div><div><br></div><div>and the classic</div><div><br></div><div><span style="white-space:pre">    '' writeStream</span><br></div><div><span style="white-space:pre"><br></span></div><div><span style="white-space:pre">as</span></div><div><div class="gmail_signature"><div dir="ltr"><div><span style="border-collapse:separate"><div style="font-size:small"><br></div><div style="font-size:small"><span style="white-space:pre">        '' copy writeStream</span><br></div><div style="font-size:small"><span style="white-space:pre"><br></span></div><div style="font-size:small"><span style="white-space:pre">i.e. literals are read-only but copies of literals are not.</span></div><div style="font-size:small"><span style="white-space:pre"><br></span></div><div><span style="white-space:pre">2. the current VM, Monticello and the ClassBuilder has full support for ephemerons, which provide instance based finalization.  For example, if a file that is the key of some ephemeron in a registration dictionary, then, with a suitable finalization process, the VM will arrange that the ephemeron gets sent finalize when the file is only referenced from ephemeris, and then the ephemeron can finalize the file itself, flushing any buffered characters and closing the file's descriptor.  What we have now is a copy of the file in a weak registry, which means we finalize the copy not the actual file.  This limits our ability to write clean file implementations.  The same applies to several other uses of weak registries.  Again Pharo is using the facility (and hence we can use their finalization process and some of their code).</span></div><div><span style="white-space:pre"><br></span></div><div><span style="white-space:pre">So the question is should we hold up the release for these features or should we go ahead and somehow arrange that we do address these (and other?) issues promptly in a subsequent release?</span></div><div><span style="white-space:pre"><br></span></div><div><span style="white-space:pre">Let me make a proposal.  We go ahead and make a release with what we have, calling it Squeak 5.5, and then follow a plan to provide read-only object support, read-only literals, and as mush of the finalizationsystem rewritten to use ephemeron (where appropriate) as we can manage by, say, September 1.  This will be Squeak 6.  And the trunk process would update to requiring a rad-only-object enabled VM immediately after the 5.5 release.</span></div><div><span style="white-space:pre"><br></span></div><div style="font-size:small">_,,,^..^,,,_<br></div><div style="font-size:small">best, Eliot</div></span></div></div></div>
</div></div></div>