The new core

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi all!

Some comments about the new src/core stuff, now that this will be frozen soon...

Thought: Would it make sense to move from dimensions-as-strings to
dimensions-as-cells now? 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).

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

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?
* should it really be possible to "hull" any given two spans? What will
the implementation look like? *How* will the semantics be?
* 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?
* can we give really a reasonable interface to e.g. video spans yet?
(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.)

Spaces should have a N() method that doesn't take a cell ID. Sliced
spaces can just create the corresponding cell in Slice 0 (the "desktop
slice"). It just doesn't make sense that when I pass a Space to some
object so that it can create a cell for itself, it needs to do
space.getHomeCell().N(). The cell is, after all, not in any way related
to the homecell! Except that it is in the same slice-- and these
semantics would be kept if Space had an N() method. (Don't get me wrong,
I don't want to remove N() from Cell, but I think it should be in Space also.)

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). Additionally, Space.rmAllObs takes an ZZObs instead of an Obs as
its argument.

Okay, that's it for the moment.
- Benja