On Tue, Jul 8, 2008 at 12:35 PM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> Am 08.07.2008 um 21:21 schrieb David Zmick:
>
>  <newbie alert>
>> 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 ;)
>>
>
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html


That's a reason.  But being able to create a system from sources provides
more benefit than that.

- 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.

- 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.

- 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.

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.


(*) 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.

<http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-May/128753.html>
>
> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080708/f03fadd2/attachment.htm