[Cuis-dev] FlatFileList

[Juan Vuletich]

Hi Luciano,

On 5/9/2022 11:07 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> ...
> I’ve been wondering for a while now how to deal with a growing image.

This is always important for me! I think we are doing reasonably well. 
The number of classes in the system grew around 15% in the last decade, 
or so. But we'd always try to do better.

> Maybe it’s not a concern for most people, but IMHO everything that 
> doesn’t absolutely need to be included in the base image should be a 
> package, and I include in that category many of the tooling that is 
> currently in the image. But a contribution that is not included in the 
> base image might feel under appreciated.

In many cases it is hard to make a decision. The criteria I adopted long 
ago is that the base image should be great for Smalltalk developers. So, 
every fundamental Smalltalk tool should be included. But not several 
alternative versions of it, or tools that are not used by the vast 
majority of Smalltalk developers.

This means that contributions that are not part of the base image 
shouldn't be considered under appreciated. Just not the main 
implementation of a fundamental functionality. Take my code, for 
instance. Nothing has been more important to me that VectorGraphics and 
TrueType in the last few years. But those are not part of the base 
image. Why? Because there is also BitBltCanvas and StrikeFonts. Only one 
of these should be in the base image. The other should be in a loadable 
package. If at some time we see no longer value in in BitBltCanvas and 
StrikeFonts, we could add VectorGraphics and TrueType to the base image. 
But only if at the same time we remove the old stuff.

> I’ve been thinking that might be good to have a list of packages that 
> are automatically loaded on image startup after asking the user, like 
> Squeak does. Or have a “standard distribution” image that comes with 
> some core packages installed. So some very useful packages could be 
> put among those core packages that form the standard distribution. And 
> maybe we could move out of the image some of the tools like SUnit, 
> ObjectExplorer, etc.

I think this could be good. The choice of packages to load should be in 
a configuration file, so, someone not wanting (for instance) 
ObjectExplorer, or wanting to add TrueType, can simply edit that file.

> Also in this way we would enforce modularity and end up with a base 
> image that changes less often, and also having simpler tools in the 
> base image would make it easier for people to make their own tools as 
> they wish (and this is a typical thing Smalltalkers like to do, I 
> think, as Stephen did with the 6 paned browser).

Agreed. Besides, I also expected the base image to change less, and more 
activity to be in packages.

> It’s just an idea, it’s not my place to make this kind of choices but 
> I thought I’d share my thoughts.

These kinds of choice should be discussed here. To come up and work on 
new ideas. And if afterwards we don't agree on a common strategy, to 
discuss and coordinate possible parallel development, like Gerald is 
doing with Haver. There's nothing wrong with doing that!

> Does anyone else wish to have a smaller and simpler base image?

Yes.

> If so, what are your ideas as for how to implement it?

I've been wanting a headless image, that maybe runs smalltalk scripts, 
for a long time. What has stopped me is the convenience of the Smalltalk 
tools! When I try to imagine how it would be to work with that, I put it 
aside and keep enjoying Smalltalk.

Thanks,
-- 

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220513/e050188f/attachment.htm>