Re: [zzdev] Re: Two hashtables per cell? No way!

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> OK, let's get this straight. What *exactly* do you want?
> 
> I think I understood:
> 1) only one CONTENT file
> 2) ZZCell.getText() returns what's in that CONTENT file
> 3) i.e. the core changes I made are changed back
> 4) a ZZLanguage -- no, we'll use it a lot, let's call it Lang -- object
> will take care of finding the right text, and of writing text in the
> right place
> 5) the view building method reads a Language param of the window cell,
> like the View and CellView params, probably as a ZOb; if none is set,
> DefaultLang is used, which just calls getText() / setText().

Not necessarily a ZOb: the 

	ZZLanguage.getLanguage(ZZCell c)

can see along d.lang-prefs whether there is anything: if nothing, return a
ZZDefaultLanguage object, otherwise the ZZPrefLanguage object. 

> What I haven't understood yet: how should the Lang object be stored/passed:
> a) as a parameter to be passed?
> b) in a static variable which is synchronized when building views --
> i.e. Lang has a public static Lang currlang; (or so) which the rastering
> method sets and synchronizes, and the cell views etc. just read that one?

I'd say a): get it in ZZDefaultSpace.getScene and pass it to the views.

The total overhead when not using the system then becomes checking one
connection and creating one object per view. And even that can be cached
later on.

	- no memory overhead
	- one virtual call, through the same object, which modern JVMs can
	  optimize away.

> The latter wouldn't be so bad, as our current system builds views one
> after another anyway. But then, what about key presses during view
> building? Should we just wait until view building is finished? Or should
> we have a seperate static Lang object for them?

Gets a bit complicated. I'd say simply the same

	ZZLanguage.getLanguage

call.

> And: how are the languages stored in the structure:
> i) on d.language/d.language-alt?
> ii) on d.content-en, d.content-de, d.content-fi, d.content-fr ... ?
> iii) in some other scheme?

My preference would be for d.translations, as then you'd see the whole
rank of the translations in all languages easily.

But that's not yet a strong point; if you can think of any for the other
systems, do tell.

> And: should I revert back the changes that pass the window cell to the
> cell views? (If not, I'll have to make them everywhere, so that we can
> get rid of the old way to call them.)

Where is that change?

> ( i) is easier to view, but ii) might be faster to access -- i) is very
> wasteful in terms of space, too -- or we could have d.language-alt as a
> dim the system deducts, like d.cellcreation and the slice dims. or we
> could have a compass raster only showing dimensions starting with
> "d.content-"... )

Why is i) wasteful in space? 

But ii) is a good alternative, too.

	Tuomas