That's what many people want. The problem is that without modularity, there's no way to make the pieces work independently. Remove Celeste, and the TheWorldMenu does a walkback. StableSqueak and the Modularity work in 3.3a both address the same problem.
Daniel
Roger Vossler rvossler@qwest.net wrote:
Hi,
I downloaded SWTBase0_5.image and SWTDev0_5.image along with the associated changes and source files from the SqF web site. I'm running this with the Squeak3.2.7Beta3 VM on a G4 PowerBook and OSX 10.1.3. Once I figured out how to use the little bootstrap program, I was able to use the Script Manager and the Refactoring Browser. Very nice.
SqF has something called VMMaker for building VMs. After digging around in the SqueakBase folder that came with the distribution, it dawned on me that having a little program called ImageBuilder that could assemble a specific image, oriented toward a specific application, problem domain, etc., from all of the stuff in SqueakBase would be very nice to have, thus avoiding all of the problems associated with namespaces, modularity, frameworks, and the like. Is this idea too simple? Have I missed something?
Cheers, Roger.....
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
danielv@netvision.net.il wrote:
That's what many people want. The problem is that without modularity, there's no way to make the pieces work independently. Remove Celeste, and the TheWorldMenu does a walkback. StableSqueak and the Modularity work in 3.3a both address the same problem.
Daniel
I very much agree.
However, [and maybe this should move to SqueakDev, except as it impacts Foundation priorities -- although I'm unsubscribed there] I think one deep issue is a deep conceptual flaw in thinking about Smalltalk "objects". This was discussed about two years ago on SqueakDev. Essentially, Alan Kay historically presents the "object" as a small computer which responds to input and outputs using a hidden state. This object lives in a world of other objects (or computers) which it communicates with. There is nothing wrong with this -- it is a fine metaphor and is very useful and leads to the notion of a live image -- which is a world of objects which communicate with each other (and the best software development environment on earth -- Squeak :-)
Where this notion breaks down is the intent (or meaning) behind the messages or sequences of messages objects send each other, as implied by the desired effect accomplished by sending a message, depends very much on the specific ecology of other objects which an object sending a message lives in. So, meaning emerges out of the specific collection of communicating objects, not just from one object and its intent in sending one message.
Classically, many other languages like C have fairly large modules (often, essentially files) which are sort of collections of functions (or objects) which sometimes work well together to define a well defined interface which the developer takes pains to preserve -- but these modules are much larger than a typical Smalltalk object (say, 1000s of lines instead of 10s). The interfaces to these larger modules are slower to change than the interface to a typical Smalltalk object, and often the interior objects and data structures just can't be accessed. The interdependencies between these C-ish modules are also perhaps slower to change, and changes within a module are usually done behind the scenes by a single developer at a time, who may be aware of some of these brittleness issues. Smalltalk historically lacks this extra layer of decoupling (or perhaps what could be called modularity). Further, most proposals to add decoupling or modularity (for example ENVY, which loads modules called applications atomically) do not address this entire issue because, for the most part, Smalltalk style permits object to object communication across modules, which rapidly breaks down clear interfaces between modules, reducing the firewall value of an extra hierarchical layer of modules.
Real world ecologies -- like a collection of bacteria souring milk -- tend to have a large number of organisms (objects) which step in at appropriate times and are each way more complex than a typical 10s of lines Smalltalk class. Also, if the system gets stuck at any one state (for the absence of some bacteria that can breakdown another's waste product) no one minds and the system just stays there until an appropriate organisms shows up through chance. In this sense, real world organisms are closer to the large modules mentioned above as opposed to Smalltalk classes, and the overall systems also have to meet lower expectations about performance.
As a consequence of all this, images tend to need specific versions of objects to achieve the designers purpose. Any changes to any of the objects tends to produce unexpected brittleness in the image. So, the image as a whole ends up evolving. This makes it hard to subdivide the image into submodules, since with objects talking across module boundaries, the brittleness will quickly return even when one modularizes. I think this is one reason some people have historically resisted modularity or building an image from scratch as opposed to evolving it towards a dedicated purpose. But, while a useful strategy, this does not directly address the deep issue of managing emergent meaning in a modular way.
I think this is a deep issue in the design of Smalltalk, and I don't have an easy answer for resolving it. One approach is essentially for images to talk to each other using well defined protocols (such as via email) within one operating system or across networks. Another resolution might be to (within a "meta-image") have objects (or small mini-images) nest within other objects hierarchically, where nested objects look like regular objects. That is somewhat easily accomplished using Smalltalk within a single image, but in practice over time the interior objects are communicated with directly by other objects outside the enclosing object, reintroducing brittle dependencies. Namespaces help a little with avoiding name and intent collisions regarding specific classes, but they don't resolve the brittleness through excessive across boundary coupling problem. What these enclosing object need is something like a "cell membrane" that prevents the interior objects from establishing close couplings with objects outside the cell membrane. Yet, that brings up solutions people glorify in C++ (friends, protected members etc.) which I think people often justifiably reject. Perhaps what I want to see is many mini-cell-like-images within an image each performing a well defined function, and duplication of class definitions in prototypes within each image a more Self like way, but with cell membrane firewalls routing messages between such cells made of prototypes. But then someone might try to start shipping flattened objects across these cell membranes which might refer to prototypes in another cell to defeat this (unless unflattening references to objects within other cells were disallowed). So it's a complex issue.
Essentially, to summarize, in order to further promote the evolution of meaning in Smaltlalk, I think Smalltalk needs a notion of a "cell" of objects, where objects within a cell can only send messages to other objects in the same cell or to the cell itself, and can only reference other objects in the cell or the cell itself. Probably this also implies moving to a more prototypish system, or at least, class definitions need to be cell specific. (As a plus, the cell can be garbage collected as an entire entity, if all its internal objects are stored in the same are of memory).
Given the above, an ImageBuilder would load "cells" (mini-images) made of specific prototypes/classes into an "ecology" (meta-image). Some cells or versions of cells wouldn't get along with each other, but that's life, and the ImageBuilder could know something about that if it knew something about the person's intent in doing the image composition.
That's one of the reasons for my lessened involvement in Squeak (and the Squeak Foundation); I don't see the big way forward to just patch Squeak or to focus on making VisualWorks-lite, which seems to be the main thrust here.
With all that said, clearly modules as currently pursued will be a big improvement for the reasons Daniel mentions.
ObFoundation: While I don't know how legitimate these people are, the National Heritage Foundation http://www.nhf.org/ (which is not the same as the conservative Heritage Foundation) lets a single individual create a public tax exempt foundation for a few hundred dollars in a week or so. They use a sort of cellular model, with these subfoundations being underneath the main foundation. Problem is, they might own copyrights and trademarks and equipment and I don't know how the liability issues (say for a patent lawsuit) would work out. I came across it as I was fishing around for an easy foundation forming process because I've decided I want to do my free software and free content work as an (unpaid?) employee of a foundation or other non-profit to minimize personal liability for unintentionally infringing software patents, being an ISP supporting a CVS repository or such which others might post infringing stuff to without my knowledge, being challenged on "fair use", etc. But I'll probably have to go the whole nine yards and make one to be on the safe side. Some links about how Apache Foundation did it are here: http://www.apache.org/foundation/records/
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
squeakfoundation@lists.squeakfoundation.org