[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: Seeking Reference Material on Certain Obscure Programming Terms

At 06:26 PM 2/2/2003 Sunday, Jeff Rush wrote:
>* stepper
>  obviously some kind of iterator; used as a base class in Udanax Gold
>  but no definition of stepper is present; must be built-in to their
>  flavor of SmallTalk.  There is some confusion over whether the
>  collection over which we are iterating can be mutated or not; hints
>  are that a stepper insulates the caller from mutations, which is
>  uncommon in iterators in other languages (C++, Python).

Came from us, not from Smalltalk. There should be a root class "Stepper" 
somewhere in the sources defining this type. As I recall, there was at least 
a message "step" that returned the next element and advanced. If I recall, 
when you ask a mutable collection for a stepper, either 

* it gives you a stepper over a copy, or, 
* if the collection is mutated, any outstanding steppers are invalidated, or,
* the collection can't be mutated until all outstanding steppers are closed 
  or something.

I don't remember which it is, but any of the above preserve correctness. The 
common iterators you refer to are examples of the kind of fragile 
abstraction we tried to avoid building -- if you use them wrong, they don't 
even blow up reliably, but just do the wrong thing.

>* passe
>  seems to be a method invoked on "self"; does it pass the call to
>  the parent class, trigger an exception as "subclass must
>  implement" or something else?  If the parent lacks such a method
>  does it quietly do-nothing or raise an exception?

This either meant "deprecated" or gone/retired. I don't remember which. Also 
our coinage.

>* fluid and emulsion
>  apparently references to an old LISP object persistence mechanism
>  that has found it's way into Udanax Gold/SmallTalk; I'm familar
>  with the persistence mechanisms of Python (pickles) and CORBA,
>  but I'd like to understand how fluid/emulsion compare.

"fluid" refers to fluid variables and dynamic scoping, as in 
http://srfi.schemers.org/srfi-15/srfi-15.html .

"emulsion" was our coinage derived from fluids. I think it was part of our 
implementation of fluids. On the C++ side, if I recall, at static 
initialization time we strung together all the fluid variable "declarations" 
on a linked list, and calculated the current size of all the fluid state. 
Then, for each thread we allocated a frame that big. I think that frame was 
the emulsion. Each fluid "declaration" would also calculate its offset into 
that frame during the same static initialization phase. A fluid variable 
access was then an access to the current thread's emulsion at the offset 
calculated by that variable's "declaration".

I know you're working on the Smalltalk side, but I just don't remember what 
we did there, except that it had adequately similar semantics.

>Jeff Rush, A Xanadu Curator of

Thanks! Keep up the good work!

Text by me above is hereby placed in the public domain