[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Seeking Reference Material on Certain Obscure Programming Terms
- To: Jeff Rush <jrush@xxxxxxxxxx>
- Subject: Re: Seeking Reference Material on Certain Obscure Programming Terms
- From: "Mark S. Miller" <markm@xxxxxxxxxx>
- Date: Sun, 02 Feb 2003 19:04:54 -0800
- Cc: udanax <udanax@xxxxxxxxxx>, xanadu@xxxxxxxxxx
- In-reply-to: <3E3DD362.20300@xxxxxxxxxx>
- References: <51C7002B020CD411824E009027C469F7822423@xxxxxxxxxxxxxxxxx> <51C7002B020CD411824E009027C469F7822423@xxxxxxxxxxxxxxxxx>
At 06:26 PM 2/2/2003 Sunday, Jeff Rush wrote:
> 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
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.
> 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
>* 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
"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