VM images and working in the VM image

Coming from a background of C++, Ruby and Java I'm used the idea that
you program in an IDE and then you output a Jar, or a bunch of shared
libraries and executables. This process involves selecting which
packages you want to use and it also involves people sorting their
software into packages and declairing package dependencies. It seems
to me (and I don't have much experience with smalltalk) that  one has
one big VM image containing the IDE and the program being developed,
but if I write a webserver for instance when I deploy the webserver in
production I don't want the IDE as part of it (probably I want to be
able to attach a debugger via a TCP connection, but that is another
issue).

Does strongtalk support the notion of packages in a similar way to
Java? Can I write a package in strongtalk, declare its dependencies,
then create a VM image that just contains my software and its
dependencies (transitive closure obviously)?

I also want to keep all my source code in files on the disk. That way
I can use existing source control systems. It must be easy to have the
VM (well some objects probably) watching the source files and reload
them if they change. That way at least one can operate even if one
doesn't yet have a GUI (e.g. the present situation with linux and
strongtalk). The file system is also a bit more trustworthy than a
running executable, e.g. if my power goes off then files are ok, but
the VM image is gone. Also source files normally don't get corrupted,
but I'm afraid that if the power goes off while I'm saving a VM image
it might get corrupted.

I think its an advantage to support more than one GUI system because
not everyone wants the same thing (some people want a GUI system that
behaves like the common ones, some people want to try something
radiacally new). In the beginning lots of people can start making GUI
systems, but after a while those that are good become apparent and
more effort goes into them.

It seems to me that package dependancies are as simple as nominating
one package for each class, and some number of dependent packages.
Then having the class loader disallow the loading of any class who's
dependent packages can't be located. It is quite usefull to make
packages into a tree, i.e. java.swing.controllers being a subpackage
of java.swing.

Packages can do other things, like static initialization, but I don't
know of too many situations where one really needs static
initialization other than for factories which seems to be a less
important idiom in languages that support reflection.

regards,

Richard.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---