Named primitives (was: Re: [zzdev] I cannot compile!)

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> Fixed. Javac doesn't like method-internal named classes.

Thanks! The new system works well & is helpful, I'd say. Funny: the day
you committed it, I'd started coding operations with names which work
the same way: posward on d.1 from the headcell on d.clone, there's the
ZOb name, and next to that, the list of structparams. I've added a
general readZOb(ZZCell) method to ZZDefaultSpace to do that reading now
that there's more than one place for it.

So besides views and flob factories, we have a new ZOb type: commands.
I've created ZZCommand after running into endless problems with
extending ZZExec, so here we are. I think this system works better and
we should get rid of ZZExec. On the other hand, the overload is bigger:
we create a ZOb every time a ZZCommand is executed. Now, as long as
they're UI callbacks and not scripted, that's no problem, and afterwards
neither if we cache.

To create a named action, the current procedure is:
- create a cell and put the name in it;
- create a new cell poswards on d.1 and put the string 'primitive' in it
(w/o quotes, of course);
- create a corner list poswards on d.1, and create a structparam named
'code' with the ZZPrimitiveAction string as its value.

In the future, we could have a Primitive module with the different
primitives being ZObs the module can create. The params like which
window to act on or the direction to use would be structparams, then.

- Benja

P.S. By the way, I suppose now that the former rasters are called
'views,' we use 'windows' for the stuff we formerly called views?
"Control window" and "data window?" Because reading the zzdev archives,
that's what they used to be called. -b.

P.P.S. Oh yes: Of course scripting engines should subclass ZZCommand so
that scripts can be called as usual UI callbacks. If we change the ZOb
interface a bit, this could also be used for inter-language calls. -b.