Re: Two hashtables per cell? No way!

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka schrieb:
> Benjamin, could you *please* figure out a less wasteful way of storing the
> texts in languages than having TWO hashtables per cell?

Well, sure. :o) What do you think about caching the last accessed
language, and re-loading every time a different language is accessed? Or
we could get rid of caching at all. But with caching we do not, as you
said, slow down those using only one language.

Then, of course, we'd need to make ZZDimSpace abstract, and create a new
ZZLocalDimSpace subclass, which stores the contents in hashtables. But
that's not a big deal, really.

> I do want internationalization but we can't bog down the system because of
> it. At the very most, it should be one hashtable PER LANGUAGE plus one
> hashtable of languages.

That's what we have "behind the scenes" now. The one-hashtable-per-cell
was b/c the old DimCell cached the contents. (Stupid reason, I know, but
I was trying to get a first version out and polish afterwards.)

> It also would have been better to for example leave the current system
> as is, and *PARALLEL* to it, build a new system which associates with each
> cell-language pair a string or a span. That would have required far less
> substantial changes and would not slow down those who do not use it.

I don't agree. Needing to make the storage more complex is bad enough;
adding the new be model plus leaving the old one really seems to much.
And I do not see what you mean by the substantial changes; the only
thing that needs to be changed in a lot of places is that CellViews,
which are responsible for what's shown in cells, need to know which
window they create flobs for, i.e. need to be given the window cell.
That's a *really* small change in most views, just adding one parameter
to the call. Everything dealing with "system text" can remain the same;
only stuff (directly) dealing with "user text" need to change, and
that's not that much.

> Also, the fact that the PrimitiveActions depend on the language of the
> *view*

It's the cell view, actually. But the current intermediate of assigning
it to a window is not so bad, I think.

> so much makes the situation a bit difficult. I think I'd almost
> prefer a model where there are simply different ZZSpace objects for the
> different language accesses, so that no code that *uses* the space would
> need to be affected at all as deeply as it is now.

I really think that wouldn't be a good idea, b/c it would make
everything "advanced," like a language preflist, so much more
complicated. (A language preflist is something which I definitely want
to see sometime: I want to be able to use German where possible, but not
see blank cells when I use an English-only applitude.)

I thought the system would work towards what you explained in your email
from August 12th, "Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Java
and keyboard?"

If I haven't understood your complaint right, please explain.
- Benja