|
|
|
|
|
|
by Rochus
2124 days ago
|
|
|
Thanks for the explanation. It's about the wording. The fellow used "whole environment" and "image based development". I used the term "virtual image" from the Bluebook to mean the same. The Bluebook says "Two major components of the Smalltalk-80 system can be distinguished: the virtual image and the virtual machine. 1. The virtual image consists of all of the objects in the system [...]". The important point here is "all of the objects", especially also the compiler. There is no Smalltalk language outside of a Smalltalk-80 virtual image. You cannot do anything in an original Bluebook system without running the virtual image. That's what the fellow referred to by "whole environment" and I by "running in a virtual image". In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. There is a compiler and and interpreter, and being "file based" is known to be a core benefit proposition of GNU Smalltalk, isn't it? |
|
|
True but the first thing the VM does if it does not give an image is create empty classes and load files that define those classes. Only then does it do whatever it was asked to do, so the ObjectMemory was not loaded from a persisted state but is effectively indistinguishable from one.
Once the image exists, the main difference between the GST file-based approach and the traditional Smalltalk-80 image-based development is that saving the image back is not "saving your work" but "preparing a cache" in which to load source files ephemerally. But that's just an additional possible use of the image that could be implemented in Squeak/Pharo as well, just like GST had class browser for development if you really wanted.