src/core, Vobs

[Rauli Ruohonen <rruohone@xxxxxxxxx>]

I just (yesterday :-) read some of the current CVS src/core, and have the
following suggestions and questions (for now):

General:
  - Why errors/ZZ*? I thought we would do s/^ZZ//g ?
  - As dimensions are now cells, why are Dim and Cell so different?
    Why not have everything necessary in Space, with Dim/Cell just being
    convenience classes that delegate everything to Space (with the
    appropriate parameters set to "id", of course)? Then Cell and Dim 
    should look very much like each other. (~'Space interface with defaults')
  - Why don't Dim and Cell have a common base class (with id, space, etc.)?
    If we're going to optimize Cell and Dim away anyway, we could at least
    make things clean.
  - Ok, so Dim may be useful as a way to let a space part define its own
    dimensions. But why a dimension? Why not "class SpacePart extends
    Space"? Speed reasons? I would opt for cleanliness in this case. The
    speed difference is probably insignificant.
  - In any case, the interfaces of the Cell, Dim and Space classes should
    be more like each other than they are now.

Cell.java:
  - getSpace() should be removed, as space is public.
  - There shouldn't be any XXX's concerning the default implementation in
    the documentation of the interface.
  - Do we really need "String t(...)" anymore? It would be nice if we did
    a full transition to spans during the "spring cleaning".
  - Hop over the end of a rank is not defined. Should it be?
  - /* zzclone ... getRootclone */ comment should be removed.
  - "Disconnect a connection from this cell" ? Cells are connected to
    cells, but connections?! Ok, I'm nitpicking here..
  - Does insert() work atomically? The documentation doesn't specify it.
    What about hop(), excise(), delete() and h()? (getOrNew obviously doesn't)
  - What is the nonexistent "@param lang" of getSpan()? Should it exist?

Space.java:
  - getDim(Cell)? Shouldn't this be getDim(String id), like with getCell()?

Then there is the Vob stuff. I think Benjamin knows the most about these,
so perhaps I shouldn't meddle with it? Shortly: In the last monday's
meeting, we discussed about the current Flob system and how it should be
simplified. The following ideas were proposed:

- The Vob class should be simple, not knowing about its absolute location,
  etc. Just a "visual object" = a hyperbox (rectangle or box in practice :-)
  with content. It should be able to draw itself, but not know anything
  about interpolation (just draw() and drawFast()). Vob can draw itself,
  if it is given the absolute hypercube it should fit itself into (thus
  taking care of both translation and scaling, enough for interpolation).
- When interpolation begins, just split the Vobs if we wouldn't otherwise
  get a 1-to-1 correspondence.
- By keeping things simple, a "2D -> 3D" Vob wrapper should be trivial.
- The "parent structure" should use Vobs as primitive building blocks and
  take care of interpolation.

It should be added that there are two ways of constructing Vob structures:
top-down, where the absolute hypercube is given and the vobs should be fit
into it, and bottom-up where the Vobs are just constructed and then
translated & scaled to the correct place. Both should work, otherwise
things will be inconvenient.

These are just stray thoughts and mostly obvious. IIRC, the Vob/VobBox
thingy did sound much like this -- am I right? Does somebody already know
how the system should work? What became of Benja's and Vesa's model?