parametrization and packages (was: globals)

[Jecel Assumpcao Jr]

On Friday 14 March 2003 17:31, you wrote:
> Slate is generally using Smalltalk grammar and block closure
> semantics, so the former is required.  Anyway, yes that's a good
> example. Generally, the thing I've been doing in this regard is to
> reduce all cross-package (named) references to specific points in the
> code, such as initializing a prototype's slot, and to just have each
> re-initialization or copy or other method simply access the types of
> the arguments' attributes for creating new kinds of those objects,
> which allows for some parametrization. i.e. the compiler could
> substitute a ByteArray for an Array somewhere and the libraries won't
> "undo" this change unless it must (say, when calling collect:).

Getting just the right amount of parametrization is a very hard problem 
and it might not be possible to have a single solution address all 
needs.

It is certainly worth thinking carefully about this since it would not 
be nice for Tunes to have its own version of "DLL hell" from Windows or 
"fragile base classes" from BeOS.

This is similar to a reference in a spreadsheet: does cell B3 really 
mean B3 or does it mean one down and two to the left? The programmer 
has to decide explicitly, but no matter what you do it will work at 
best most of the time and never all of the time :-(

Another example is package dependence in systems like Debian. Do you 
really meant that your packages needs Apache X.Y or will any web server 
do? They had to create "virtual packages" to introduce a reasonable 
level of parametrization, but their solution is still far too brittle 
in my opinion.

> I have been considering making a package object that represents a
> "configuration" of objects and methods with requirements and
> provisions. This kind of constraint definitely affects that.

Self has the "transporter", but it is very limited. See

David Ungar. Annotating Objects for Transport to Other Worlds. In 
Proceedings of the 1995 ACM Conference on Object-Oriented Programming 
Systems, Languages, and Applications (OOPSLA '95), pp. 73-87, Austin, 
TX, October 1995.

> Certainly Slate does not fully support in-place editing; a good
> example is that we can't remove methods or perform other such
> queries. Anyway this will go away once bootstrapped.

Without the right low level memory management support this can't be 
added later. You need something like Smalltalk's #become:

-- Jecel