Re: [Fwd: [zzdev] The new core]

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> 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,
> Obs). 

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.

	Tuomas