<br><br><div class="gmail_quote">On Tue, Jul 8, 2008 at 12:35 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Am 08.07.2008 um 21:21 schrieb David Zmick:<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<newbie alert><br>
Ok, I have a question.. What is this for? The idea kind of makes sense to me, but I am not sure I understand what to use it for, which is i guess why I don't get it :( Sorry for interupting you high-level discusion with my simple question ;)<br>
</blockquote>
<br>
<br>
</div><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html</a></blockquote><div><br>That's a reason. But being able to create a system from sources provides more benefit than that.<br>
<br>- it allows more speed and flexibility in deciding how the system is implemented since the bootstrapped system doesn't necessarily have to be an evolution of the current system.<br><br>- it is much easier to build systems up from components than find out what can be taken away to keep something running, so producing a minimal deployment of some application is much easier using a system built from the ground up.<br>
<br>- a system built in this way doesn't have to be a complete Smalltalk. It can, for example, omit a compiler, or omit reflective parts of the system without which one couldn't inspect, make modifications to the class hierarchy, decompile, etc, etc. So a system built from teh ground up is much more easily made secure.<br>
<br>But the most compelling reason for me is to do with the system's architecture. The Smalltalk system should be architected as an onion, each layer of the onion being composed of a set of components (like techtonic plates). If it is architected like this, with components at the centre not using anything in outer layers (*) then removing components becomes much easier. So the normal mode of development is to develop an application in a large well-facilitated development image. Once developed the programmer clones the image and unloads the components they think they don't need and tests the resulting application. That differs from the current strippng approach in that one is removing coarse-grained components with well-understood functionalities and boundaries instead of trying to infer the subset of code still used by the system. So starting from a system that is built from the ground up should enable Squeak to evolve into a properly modular system.<br>
<br><br>(*) I am assuming that components do include class extensions so that e.g. when one adds the "Tools-Inspector" component it does extend classes in the kernel layers beneath it with appropriate extensions to permit their inspection.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html" target="_blank"></a><br>
<font color="#888888">
<br>
- Bert -<br>
<br>
<br>
<br>
</font></blockquote></div><br>