[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Nile
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: [zzdev] Nile
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Mon, 18 Dec 2000 20:39:31 +0100
- Cc: zzdev@xxxxxxxxxx
- References: <20001209043511.B17413@xxxxxxxxxxxxxx> <3A33A557.31FE4891@xxxxxx> <20001210185537.D15044@xxxxxxxxxxxxxx> <3A33DE1D.375C90A6@xxxxxx> <20001210224318.A17858@xxxxxxxxxxxxxx> <3A34009B.FB990E0@xxxxxx> <20001211015201.E18012@xxxxxxxxxxxxxx> <3A342176.B03A9B9F@xxxxxx> <20001211035226.B3587@xxxxxxxxxxxxxx>
Tuomas Lukka wrote:
> > If we use cells as dimensions, of course. Do you already have solutions
> > for the obvious problems? :)
> Which are the obvious problems?
How do I know two dimensions are same in two different ZZ spaces? Practically:
* how do I know two dimensions are same in slices?
* how do I reference dimensions in the code? (which dimension is d.nile?)
> > > > > Now the question remains of whether it's possible to make it efficient.
> > > >
> > > > Hm -- should be, because a cell could know the applitudes it belongs to,
> > > > by checking its connections on the respective dimensions while being loaded.
> > >
> > > A cell can be in several applitudes.
> > >
> > > If I have an anchor in the text that I've connected to one applitude and connect
> > > it to another, that would have to be noted somewhere.
What about this: we start with each applitude having *one* dimension
that is used for designating that some stuff belongs to it -- e.g., Nile
has d.nile-special. Then, when an applitude view (say, nile) encounters
a connection to something else, it calls a method in the VobSet. The
VobSet searches all dimensions on the applitude table. When it finds a
connection, it calls the view of the applitude associated with that
dimension to show the connected piece.
Or wouldn't that be powerful enough?