[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [Fwd: [zzdev] The new core]
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [Fwd: [zzdev] The new core]
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sun, 15 Apr 2001 02:31:50 +0300
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3AD8D429.57274857@xxxxxx>; from b.fallenstein@xxxxxx on Sun, Apr 15, 2001 at 12:50:18AM +0200
- Mail-followup-to: "B. Fallenstein" <b.fallenstein@xxxxxx>, zzdev@xxxxxxxxxx
- References: <3AD8D429.57274857@xxxxxx>
> Thought: Would it make sense to move from dimensions-as-strings to
> dimensions-as-cells now?
Just committed. Good idea.
> One possibility would be to keep ZZCell as a
> subclass of Cell for the time of the move, ZZCell having methods which
> take strings and convert them to cells internally somehow (e.g. by using
> the dimension string as the cell ID).
No way. This is spring clean-up time. It's actually good that all
code has to be touched.
Cell is a final class.
> getOrNewCell() -- I still think that should be just getOrNew(). Besides,
> it should really work not only for one step, i.e. getOrNew(dim, +7)
> should go up to seven steps poswards (say, four if there are four cells
> in that direction) and create the remaining case (three in the example).
> The last one should be returned. (If that's ok with you, I'll change it,
> I've just written some code for that in the Archimedes procedural clang
> layer stuff.)
(Discussed on IRC, agreed on putting it in ZZUtil for now)
> Should spans really be in there already? Are you that sure about the new
> kinds of spans you're cooking up? E.g.,
> * should image spans really be limited to rectangles?
Yes. Filters can be added on top of those.
> * should it really be possible to "hull" any given two spans? What will
> the implementation look like? *How* will the semantics be?
The hull is meant for building trees, not getting content. So it's
basically a union op for building enfilades.
> * should Span itself really not have any kind of address? If so, what is
> "hull" supposed to mean? How are span sets supposed to work efficiently?
As trees, using hulls ;)
> * can we give really a reasonable interface to e.g. video spans yet?
That's why it's just a placeholder for now.
> (BTW, I'd say stereo audio should be handled by having to distinct
> channels, which of course correspond to two distinct spans. You should
> be able to mix them anyway-- otherwise, the span system would be just of
> *no* practical use for audio.)
I don't know. Another good argument is that an audio span should
be allowed to have several channels but that you can mix them afterwards.
> Spaces should have a N() method that doesn't take a cell ID.
Done. Defined to be equiv. to N(getHomeCell()).
> It seems that in some Cell methods, the passed observers are just
> discarded, namely in N(String, int, Obs) and h(String, int, boolean,
The first one does pass it along. The second one didn't, that
was a bug.
> Additionally, Space.rmAllObs takes an ZZObs instead of an Obs as
> its argument.
Right. The ObsTriggers needs work as well.