Some time ago I have written down some thoughts (with great ASCII
graphics! ;-) ) about structuring packages titled
	Structuring packages to minimize 'bad' dependencies
in
	http://minnow.cc.gatech.edu/squeak/779
.

I would like if someone would take a look onto it...

Greetings,

Stephan

PS.: Don't mix me up with one of the other Ste*an*'s...

Paul McCullough wrote:
> 
> I read with great interest Stefan's (and Paul Fernhout's et al) postings
> re: making a small image.
> 
> Looking through recent postings, some folks want to remove MVC, some want
> to remove Morphic, some want a minimal system, some want to deploy
> reasonable-sized apps.
> 
> With many projects I've worked on,  I've encountered similar needs: "we
> need to make the image smaller", "let's develop a minimal image", "the
> delivered product is too large", "we'd take out the unneeded code if only
> we could identify it".
> 
> The earliest suggestion I personally know of to develop a minimal ST80
> image came from Steve Putz while I was at PARC sometime around 1984-5. The
> problem is not new.
> 
> The various image strippers, or tree shakers, have problems -- believe me I
> know. I've used tree shakers in three major Smalltalk system,. Heck , I've
> written some of them. Tree shakers suffer from the problems noted in the
> Tales Of Dying Objects postings.  In particular, deep knowledge of the
> system is needed, that knowledge is not easily gleaned, that knowledge is
> easily invalidated in subsequent releases because someone (perhaps you,
> perhaps an unknown person) made a connection between two parts of the
> system without considering how that change would affect the tree shaking
> code. It's sort of like sculpting a block  of marble: in the hands of
> Michelangelo, a great masterpiece emerges. In lesser hands, you are likely
> to get rubble. You did back up your image didn't you?
> 
> Tree shakers also suffer because they typically remove entire classes --
> but sometimes the cruft is  simply methods in "system" classes. All those
> little methods add up -- it's sort of like backpacking. You never put
> anything heavy in your backpack --so why does it weigh 70 pounds the first
> time you pick it up? How can I tell, a priori, if I can safely remove
> Object>>flash? For that matter, how can I tell post priori? Same problems
> for Object>bindingOf: and many other messages in "system" classes.
> 
> I suggest we consider moving Squeak to a different style of development --
> one in which we can deliver stand-alone apps of minimal size and, perhaps,
> still support the free-wheeling style which many have grown accustomed to.
> I freely give credit here to Allen Wirfs-Brock who asked some of these
> questions years ago. Hopefully, Allen will add to this discussion.
> 
> What can be achieved? I seem to recall Allen saying that Hello World in
> Allen's Modular Smalltalk was under 64k (contrast that to a C-based
> X-windows  version...).
> 
> In nearly every other programming language, you can point to the source
> code (which many be in several chunks) and say "that is my program".  In a
> current Smalltalk system, that task is oddly difficult. When the Smalltalk
> aficionados were showing the ST80 system to neophytes, the most common
> question was "where is the program"? It's hard to answer because the
> programmer has great flexibility in Smalltalk: you can easily
> extend/override a system class; you can rely on a method that you think is
> a system method -- but which came in with the mail reader. You can remove
> methods you deem incorrect from someone else's classes. It''s easy to
> loosed a change from a changeset. Of course, one of the blessings of
> Smalltalk is the lack of boundary between system and user classes. But when
> it gets to be time to release a product, those fuzzy boundaries feel more
> like a curse.
> 
> There are those that argue that a source management system will fix these
> problems in Smalltalk. Indeed, I've seen and used several such systems. In
> my opinion, they didn't cut it: too big, too complex, too non-Smalltalk,
> too authoritarian.
> 
> So what, in my opinion, would help? The one thing I've heard of (alas, no
> direct experience) was the Firewall project that Allen Wirfs-Brock & Steve
> Messick (and probably others) worked on. Have a development environment
> where pretty much anything goes. And a target environment which starts out
> empty. If the user doesn't say to add class Point to the target, it isn't
> there. Not much different from importing packages or classes in Java. Or
> having include files in C. But, in those languages, I can easily say "this
> is my program." And I can easily make a reasonable-sized executable. Of
> course, we'd still allow you to modify a system class if you needed to --
> but you'd only be modifying it in the target.
> 
> Doing the work this way means you don't remove stuff to make a headless
> system. Instead you add the stuff to make Squeak have a display. You don't
> have fights over whether to remove MVC this month or next, you load it if
> you want.
> 
> One very necessary item missing from Java and C is versioning of packages.
> It can be pretty frustrating moving a working Java program from, say,
> version JDK 1.1 to JDK 1.2. Stuff that used to work doesn't. Methods have
> been deprecated. Work-around methods may not have been well thought out. It
> would be so much easier if when you imported package foobar that you said
> you imported foobar  version 1.1. Then, you could continue to import that
> version and your program could continue to work.
> 
> So what would it take to make such an environment? Allen and Steve have
> much more experience at it than I. But as a first cut, we would need to
> break the system into small packages -- the packages will have to have
> pre-requisites. Be sure the packages can be compiled -- Squeak is probably
> better off that ST80 where some objects existed in that image as a result
> of executing doIts alone -- the source code was long since lost. Clas
> Object could be much smaller -- extensions for C code generation would be
> in that package, not the base Object. Ditto for Morphic extensions. And
> object segment extensions. And on and on. Build tools and a VM which can
> talk via a simple connection between the development environment and the
> target. Provide a way to squirt classes and individual methods across the
> interface. Debugging would run in the development environment and use the
> simple connection to control execution on the target. Modify the
> programming tools to know which environment they are working on.
> 
> This work won't be easy -- as we try to slice and dice the image, other
> folks will be adding stuff in subsequent releases, and the number of funky
> connections between classes will increase. While we're trying to make
> Object small and elegant, other folks will be adding new  (and strange)
> methods. Reminds of a project where I added a database to a quite complex
> Smalltalk-V system. Due to market needs, the team couldn't stop adding new
> features while I did the database work, so I had to track everyone else's
> changes. By the time we reached congruence, Ward Cunningham likened the
> work to doing a heart-liver-lung transplant while the patient and surgical
> team were all running uphill.
> 
> Thanks for reading this far. I fear I should go back and tidy up the
> writing and more clearly express ideas, but it's late and I'm tired.
> 
> I have some spare cycles coming up. I am seeking others who think this an
> interesting goal to pursue and are willing to commit to making it happen.
> 
> Cheers,
> paul

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3