parametrization and packages (was: globals)
Jecel Assumpcao Jr
Fri Mar 21 13:35:02 2003
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
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: