Re: Two hashtables per cell? No way!

[Tuomas Lukka <lukka@xxxxxxxxxx>]

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. 

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

Hmm... currently everything is always loaded in memory anyway so we can
easily do that. 

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

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

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.

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

True...

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

Actually it would not make that impossible at all: the language prefs
would be interpreted by the space. What I mean is several ZZSpace objects
acting as fronts to the same space, with getText() simply doing something
different.

But it's probably not good.

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.

So the code to render the window *SHOULD* be like

	using_language(ZZDefaultSpace.getLanguage(winCell)) {
		raster.render();
	}

which is unfortunately not possible.

> 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?"

Possibly, but I don't remember what I wrote then and have probably learned
a lot since ;) ;)

But anyway, let me reiterate: please use a branch for such changes in the
future. That makes trying out things, testing and coordinating much
easier.

	Tuomas