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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka schrieb:
> 
> On Sat, 14 Oct 2000, Benjamin Fallenstein wrote:
> > 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.
> 
> Not true. You create two hashtables when creating a ZZCell object, which
> uses memory which in turn slows us down. You also pass extra arguments
> ("en") to routines, compare with it etc.

I meant with caching the last accessed language. (I.e., using the old
model inside the DimCells and save the last accessed contents in it;
when the same language is accessed again, the cached contents are used.)

> > > 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.)
> 
> In such case, I'd suggest starting a new CVS branch if there's a major
> change that touches the core. That way the change can be discussed and
> developed before it affects any other code.

I can see reason in that. :) I'll remember to do so next time.

> I mean, I'd like a model where there's a "Default text" and then "language
> text", and default text is fast to access.
> 
> I *don't* like
> 
>         a.getText()
> 
> being redirected to
> 
>         a.getText("en")
> 
> at all.
> 
> In my spaces, I will be liberally mixing Finnish and English and possibly
> want to be translating either to either later.

Yeah, you've definitely learned a lot since. You wanted English to be
the default language. ;o)

No, no, no, but what about redirecting it to a.getText(null)? This would
mean "no assigned language," and it would usually be on top of the
language preflist. There would be a mode where all newly entered text
goes into that content storer. You could then have key bindings like
Ctrl-E and Ctrl-F which transfer the content to a different content
storer (en and fi in this case).

But then, all the cells generated by the system would have "no assigned
language," although they're very definitely in English?

That's basicly the reason why I used the redirection above: the system
cells *are* in English (even though it's not the most poetic kind).

A possibility would be to have the not-assigned mode a.getText(null),
but to redirect a.getText() to "en". (side note: I think of a.getText()
as "get system-readable contents", b/c everything else would *truly*
need a lot of changes in the code.)

Urgh, just realized: but numbers don't have a language! Yuck. So maybe
system == no language assigned isn't SO bad. But "CellViews" is still
very definitely English...

Or maybe we define the a.getText(null) as "Computercode." :-}

> One thing I also don't like at all is that *all* things that paint text to
> the screen now have to take into account the language, if they want to be
> i18nable.
> 
> Java doesn't let us do it but having a language context in the window
> would be far better, so that simple getText() would always return the
> right thing for each window. That would be ideal.

Um, but what about the reads which want to get "code" -- like "true,"
"CellViews," etc.? -- We'd have that problem with different ZZSpace
objects, too, wouldn't we? (Or maybe we'd have a getText() and a getCode()?)

Yeah, it's not nice that everything has to think about the language...
we could have a.getText(window cell), although basicly ZZCell is not the
place to put things which are that specific.

- Benja