>I'm a Squeak newbie.  One question I have is how to make one person's
>code run on another person's image after the end-user has changed
>who-knows-what in his system.  You don't have a consistent API provided
>by hardware/OS/Java/etc.  Some changes, e.g. UI behaviour, should be
>preserved, while others might cripple the new code.

Let's define who's the user or person.  If you talk about end-user, that
is, people who get you image as they'd use any other "exe" program, there's
no problem.

If you're talking about one programmer who wants to use another
programmer's code, things become more difficult.

>Is this a problem in practice, or does everyone keep enough of a
>consistent base to allow other people's code to run with no major
>modifications?  Right now, it sounds like all users are sophisticated

IMHO this is the main problem with Smalltalk and probably one (if not the)
reason that there's no pool of components and libraries of Smalltalk code
as there's for probably any other language.  Unfortunately, trying to use
other programmer's code can mean that you've to check every line of code
just to make sure that both of you used the same assumption about the code
(the same base image) and that the new code doesn't conflict with our own
code or the code of a third programmer.

>enough to make modifications themselves, but if you want children to use
>Squeak and install "applications"....

Impossible, if you ask me. At least nearly impossible.

>Has anyone else been thinking about this?

Here're a few rules that might help, however they only work if all parties
respect them.  They try to assure that your code bears minimal dependencies
with the base system.

1. There's a base image.  Respect it and never change existing code.  Don't
modify class definitions (add/remove instance/class/class instance
variables, add/remove/modify pool dictionaries, change the superclass),
don't remove classes, do not even dare to modify or delete a method.

2. Separate your classes.  Make sure that you don't pick class names other
people might also use.  The best idea is to create your own (pseudo)
namespace by prefixing all classes with your initials or some project
abreviation.

3. Adding means modification, too.  Do not add methods to base classes if
you do not absolutely need.  Even this will modify the base system.  If
this can lead to name clashes.  If you need to add methods (and you aren't
using some well know frameworks like for printOn:), make sure you create
your own name space by prefixing, i.e. use #abcIsList instead of #isList.

4. Reduce class-dependencies.  Don't create subclasses if you don't have
to.  Use composition patterns instead.  For example, there's never a need
to subclass a Stream. Instead of this, implement a stream-like protocol
(you probably need only a hand-full methods of Stream anyway) in your own
Object-subclass and delegate methods to an embedded Stream instance.

5. Reduce method-dependencies.  Never add methods to base classes which
would change the method-inheritance-list. For example don't add a
printString method to Array. Anybody would expect that Array inherit
Object's implementation.

6. Respect the public protocols.  Never use methods of the base image of
protocols which are declared as private or which are placed into no or
dubious categories.  Unfortunately, there's no better rule of thumb.  If
the method is already mentioned in Smalltalk-80, the Language or any bother
really old Smalltalk book, there's a high change that it is okay to use but
otherwise, you're totally dependent from the creator of the base image. If
there'd be a real documentation which could be used as a contract (or at
least promise) that these method will be kept and will not change its
semantics, things would become simpler.

7. Distributionability.  Make sure, that you code can be successly filed-in
and can also successfully removed without any harm.  The best idea is to
either provide a special removal file-in or provide some #uninstall method
(a central install/uninstall mechanism already present in the base image
similar to what Windows and InstallShield provides would be a big plus).
Sounds very obvious, but a lot of people incrementally create their
application and then neither know what code belongs to it nor how to remove
it again.

8. Help improving the current situation.


bye
--
Stefan Matthias Aust  //  Are you ready to discover the twilight zone?