[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Proposal: Unify cells and steppers
- To: zzdev@xxxxxxxxxx
- Subject: Proposal: Unify cells and steppers
- From: Benja Fallenstein <b.fallenstein@xxxxxx>
- Date: Tue, 2 Apr 2002 13:04:55 +0300
Whoops-- now I've found my earlier mail! ;-)
Regarding the plans of moving towards using Steppers instead of Cells. A Cell
is an immutable object representing a single cell. A Stepper is a mutable
object that represents a cell at any given time, but that can be moved across
cells. Using Steppers may ease the task of compiling optimized code.
(Note: We're talking about Java objects here, not about in-ZZ objects. This
is a completely technical issue.)
I do think that Steppers have applicability even now, even though I don't
think we should go into compiling just yet (see my other mail): We create too
many Cell objects, especially Cell objects that represent single characters
on a vstream.
Currently, Steppers are black-box objects intended to allow implementations
to supply their own fields. I propose to give them the same fields that Cells
have, instead. The set of fields in Cell is optimized for vstream cells,
which are our main concern for now, and to a lesser degree for cells in
slices, which are our lesser concern for now.
Making Steppers have the same fields would allow easy interoperation with
Cells. Specifically, it would be trivial to set a Stepper to a Cell by simply
copying the fields. It would also be possible to set a Stepper to the
position of another Stepper, by copying its fields (as the fields in a
Stepper would be known). It would be possible to have efficient Dim
implementations know about the fields in a Stepper, modifying them. It would
mean that Steppers would not have to do classcasts on black-box StepperDims
(instead, the normal Dims could be used).
To create Dims making efficient use of this, we would probably need to create
our own implementation of hashtables; on the other hand, it might also be
possible to extend the current PlainVStreamDim to handle vstream cells
efficiently without going to that length, though on the other hand, the
result may be more twisted than if we just implemented the custom hashtables.