[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: zzdev@xxxxxxxxxx
- Subject: src/core, Vobs
- From: Rauli Ruohonen <rruohone@xxxxxxxxx>
- Date: Tue, 17 Apr 2001 12:18:07 +0300 (EET DST)
I just (yesterday :-) read some of the current CVS src/core, and have the
following suggestions and questions (for now):
- 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.
- 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?
- 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?