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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

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

Interesting: I just sent a message asking you to explain this ;)
 
> 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.

And caching is actually an explicit reason for ZObs. However, even so the
system is surprisingly fast: we tried making a lot of cells and with 30000
cells it still runs very well, and a getHeadcell on 16000 cells is
instantaneous.


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

Yes.

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

How?

	Tuomas