This is fantastic!

Some of my earlier experiments in the composable-UI vein used Lua, but I found that it was easy to run up against both coroutine problems (lack of preemption) & limitations in the maximum number of identifiers in the global namespace. Your work here looks a lot more advanced than mine ever got.

(My current prototype is in Io, but I discovered that I would essentially need to rewrite Io to get a working system, because it stopped being maintained years ago & has problems with its speculative execution based thread planning.)

I found it great! And adding message passing and encapsulation was super easy! Owen Densmore’s “Object Oriented Programming in NeWS” he presented at Monterey 86 Usenix Graphics Workshop showed how to do that in two pages of code!

Object Oriented Programming in NeWS, by Owen M. Densmore, Sun Microsystems. 1986 Monterey Usenix Computer Graphics Workshop. 1986. http://donhopkins.com/home/monterey86.pdf

This led us to look for a formalization of this style. A Smalltalk-like class mechanism seemed to fill this need. Just before our beta release, therefore, we decided to look for the extensions we would need to make to PostScript to support classes. Much to our surprise, PostScript could implement classes with no modifications! The secret is PostScript dictionaries.

NeWS’s object oriented PostScript dialect is based on SmallTalk’s model, and implemented with PostScript’s dictionary stack (which is purely dynamic scoping: just look up names in the dictionaries on the dictionary stack in order of precedence).

It was very straightforward to inspect and modify running code! PostScript is totally homoiconic (“not that there’s anything wrong with that” ;) – code is simply normal data like arrays (whose executable bit is set). And objects and classes are just normal dictionaries, pushed onto the dictionary stack in search order.

It supported multiple inheritance, which we used a lot.

Sidebar: But we weren’t as multiple-inheritance-happy as ScriptX was, whose collections (arrays, dictionaries, sets, etc) were classes that many parts of the system inherited from, like the containment and clock hierarchies and timelines (you call the array append method to add children to them), while in PostScript (as in JavaScript), arrays and dictionaries are built-in, primitive non-object types, that you can use to build classes and objects but aren’t inherited from directly themselves (so you call addChild to append children to them). What I mean is that in PostScript (JavaScript), dictionary (object) is not class that other objects INHERIT from, but it is the primitive data type that classes and objects are CONSTRUCTED from.

But to contrast with PostScript and JavaScript, ScriptX was designed from day 1 to be an object oriented system with multiple inheritance, so collections are first class objects that you can easily subclass and mix in to your own classes that like to contain things or act like maps, so all the normal iterating and filtering constructs and collection methods worked on them. So in ScriptX you don’t loop over a container’s children, you loop over the container itself, since doesn’t HAVE and array of children, it IS an array of children.

Flounder: I can’t believe I threw up in front of Dean Wormer. Pinto: Face it, Kent. You threw up ON Dean Wormer. -Animal House

The syntax for sending a message to an object was “/foo obj send”, where “/foo” was like (QUOTE FOO) in Lisp, a literal name. Executable names are looked up on the dict stack, and their values executed (pushed onto the execution stack). Literal names are just pushed onto the operand stack.)

“obj” resolved to some object (and could be pushed on the stack any way, you didn’t have to give it a name like “obj”, it just had to be in the right place at the right time).

And “send” took the name of a message (or an executable array), and an object. It first established the context by pushing all the target object’s dictionaries on the stack (the old version didn’t bother to pop the old object’s dicts off, but later versions did). Then it looked up the name on the new dictionary stack (or just used the executable array you passed in), and executed it. Then it restored the previous context.

Passing in an executable array to send instead of a message name was kind of an optimization shortcut, and formally it should be methodcompiled, but if you knew what you were doing (like you just wanted to send a sequence of consecutive message to the same object and didn’t want to pay the cost to ping-pong back and forth between contexts) you could just methodcompile it by hand and coalesce the messages into an executable array of executable names (and other parameters and operators if you wanted).

In this way PostScript was a lot like a dynamically scoped Lisp with macros!

You could also send the /promote message to an object with a name and a value as an argument, to dynamically define an instance variable. Or send an /installmethod message to an object with a name and a method. It would dynamically methodcompile the method into the object’s scope and install the method on the instance as a local method.

That is one of the important properties of a prototype based object system, that you can dynamically attach methods and properties directly to instances, and later undefine them when you want!

The layout and painting code would often lazily promote cached measurements into the instance on demand. There would be a “backstop” method in the class that computed an expensive value and used /promote to cache it in the instance, overriding the backstop method, then later like in /invalidate or /resize, other methods could clear out any invalid cached methods or properties when something changed that they depended on, so they’d be recomputed and cached back on demand.

NeWS objects didn’t contain “self” references to themselves, but there was a function called “self” that figured out what the current object was by searching the dictionary stack top to bottom for an instance dictionary with a “ParentDict” key (later optimizations put a shared “ParentDictArray” in every instance of a class, which was quicker for switching contexts and searching than following links).

So it wasn’t very optimal to call “self” all the time, but formally you were supposed to. There was a very simple “method compiler” (like a Lisp macro) that optimized sends to the same object like “/foo self send” (push literal /foo, figure out self, and send message /foo to it) into just “foo” (look up foo on current dictionary stack and execute it without switching context), and it resolved “/foo super send” references to a direct inline references in the code (like “/foo supersend” so no dynamic resolution was necessary.

Here is all there was to the (original version of the) method compiler (later versions may have been a bit more complex but not much more).

% Crack open the methods and fix for "super send" and "self send"
/methodcompile { % method parentdict => newmethod
    10 dict begin
        /superpending false def
        /selfpending false def
        /parentDict exch def
        [   exch 
            {
                dup /send eq superpending selfpending or and {
                    pop pop
                    superpending
                        {parentDict /className get cvx /supersend cvx}
                        {cvx} ifelse
                } if
                dup type /arraytype eq {parentDict methodcompile} if
                dup /super eq /superpending exch def
                dup /self eq /selfpending exch def
            } forall
        ] cvx
    end
} def

And here’s all there is to send, supersend and self (later send was fixed to pop the previous instance off the stack before sending and restore it when done, and object’s parentDict key was changed to parentDictArray, and I think send was eventually implemented as a build-in operator since we used it so much):

% Generic Smalltalk-ish Primitives.
% Send a message to an object.
/send { % <args> message object => <results>
    dup /parentDictArray get {begin} forall
    begin
    cvx exec
    parentDictArray length 1 add {end} repeat
} def

% Send a message to super without popping myself.
/supersend { % <args> keywordmessage superclass => <results>
    exch { 2 copy known {exit} {exch /parentDict get exch} ifelse } loop
    get exec
} def

% Put me on the operand stack.
/self {/parentDict where pop} def

Here’s another great early resource about NeWS programming. But it doesn’t cover the later refinements like multiple inheritance and optimizations, like using dict-like canvases, events and processes (threads) directly as objects (for making the actual canvases on the screen, event interest templates and event managers, into objects themselves, instead of separate objects just referring to them):

The NeWS Book. An Introduction to the Network/extensible Window System. James Gosling, David S. H. Rosenthal. Michelle J. Arden. David A. LaVallée. Sun Microsystems. 1989. http://donhopkins.com/home/The_NeWS_Book_1989.pdf