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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

... or what about a ZZLanguage object, which is passed and has a String
read(ZZCell) method, which <everything that draws text on the screen> is
supposed to use?

This'd implement language preflists and the like. (Would also have a
write() method for ZZPrimitiveActions etc. And it could be somehow
associated with the window cell and retrieved through it?)

Not perfect either, of course...
- Benja



I wrote: 
> 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