[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] src/core, Vobs
- To: Rauli Ruohonen <rruohone@xxxxxxxxx>
- Subject: Re: [zzdev] src/core, Vobs
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Tue, 17 Apr 2001 17:25:07 +0300
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <Pine.OSF.4.10.10104161837420.21029-100000@xxxxxxxxxxxx>; from rruohone@xxxxxxxxx on Tue, Apr 17, 2001 at 12:18:07PM +0300
- Mail-followup-to: Tuomas Lukka <lukka@xxxxxxxxxxxxxxxx>, Rauli Ruohonen <rruohone@xxxxxxxxx>, zzdev@xxxxxxxxxx
- References: <Pine.OSF.4.10.10104161837420.21029-100000@xxxxxxxxxxxx>
> - Why errors/ZZ*? I thought we would do s/^ZZ//g ?
Hmm... probably.
> - 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.
This is something we're currently discussing a lot here in Jyväskylä.
> Cell.java:
> - getSpace() should be removed, as space is public.
Done
> - There shouldn't be any XXX's concerning the default implementation in
> the documentation of the interface.
Done (about)
> - Do we really need "String t(...)" anymore? It would be nice if we did
> a full transition to spans during the "spring cleaning".
This has other implications too: e.g. a cell should contain referential
text so a RString would be one possibility. But cell content is actually
a complex question.
> - Hop over the end of a rank is not defined. Should it be?
No, the point is that different dimensions may want to do different
things there.
> - /* zzclone ... getRootclone */ comment should be removed.
Done.
> - "Disconnect a connection from this cell" ? Cells are connected to
> cells, but connections?! Ok, I'm nitpicking here..
Done
> - Does insert() work atomically? The documentation doesn't specify it.
> What about hop(), excise(), delete() and h()? (getOrNew obviously doesn't)
Hmmm... they should be but it's not guaranteed at the moment. Will have
to benchmark synchronized{}. At the moment, it is the intent that a Space
be used from one thread at a time only.
> - What is the nonexistent "@param lang" of getSpan()? Should it exist?
Related to the above getText complexity: multilingual cells.
> Space.java:
> - getDim(Cell)? Shouldn't this be getDim(String id), like with getCell()?
Nope. getCell is getCell by id, but dimensions are identified by cells.
getCell should actually be pretty rare.
Actually, with final cells anyone can construct new Cells so we might not
even need it...
> - 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).
I'm now thinking that it should know it but that the interpolation should
be elsewhere.
Tuomas