Hi Eike, On Tue, 2008-12-09 at 20:41 +0100, Eike Rathke wrote: > Hi Kohei, > > On Tuesday, 2008-12-09 13:20:48 -0500, Kohei Yoshida wrote: > > > > >> Again, modularization. We want to separate the Excel filter from the > > > >> "sc" module, and opcode mapping is part of it. > > > > > > > > But VBA is not part of the filter, and we need that for VBA. The filter > > > > is merely re-using it. > > > > > > > > There is a fine line between modularization and reusability. > > > > > > To share something between the filter and VBA, it doesn't have to become > > > part of the Calc core. > > > > On the contrary, I believe this opcode map does belong in the core. > > Doing it any other way, especially a duplication of opcode in various > > places, is a kludge. > > The new mapping actually would duplicate things once the resource > strings differed from the Calc English ones, if I understood that > correctly. So far the core did not need to know any Excel specific name > mappings, those were setup by the filter using the token API. I'm > probably repeating things, but we spent quite some effort to separate > that.
Understood. Judging by the amount of code written for it, I have no doubt that it was a lot of effort. > > Btw, in the code committed, ScCompiler::InitSymbolsEnglishXL() uses > ScGrammar::GRAM_ENGLISH, I think that should had been > ScGrammar::GRAM_ENGLISH_XL_A1 instead. Yup, you're right. ;-) I gotta fix that. > > While it's important to separate out things from > > the core, there are still things that *do* belong in the core. > > > > > This is now the second change surfacing from ooxml02 which runs contrary > > > to the separation of filter and core. > > > > Once again, VBA is not a filter, and I don't see how that would > > contradicts the separation of filter and core. > > Wouldn't it be possible to let VBA create a mapping similar to how the > filter does it, by using ScCompiler::CreateOpCodeMap() and > ScCompiler::SetFormulaLanguage()? It's possible, for sure. But not without a fair amount of refactoring I imagine (Noel would probably know more about this). And it won't be as easy as having ScCompiler take care of the opcode mapping internally and having VBA just specify the grammar. > Btw, where is the difference between > names VBA uses and names Excel uses in MOOXML? So far I'm not aware of any differences between the two. > If there isn't any, > wouldn't it be "natural" to share the filter's name mapping with VBA? Absolutely, and that's what I envisioned too. What we seem to disagree is where to keep the shared filter name mapping instance. For me, it seemed natural to keep it with ScCompiler, the same way we keep the various address convention code within that class, and have it shared by xls import/export filters and VBA parser. But you prefer the opcode mapping outside the core, in oox. That would work fine for the filters (once the export filter moves to oox). But once VBA gets into the mix, it becomes a little ugly since the VBA code is still in sc. Let's say we agree to keep the opcode mapping outside the core (after all, it's already done). But the problem, at least in the short-term, is to 1) refactor VBA to use the FormulaParser API instead of using ScCompiler directly (like it does now). 2) move the xls opcode mapping out of oox to a place where it can be accessed both from oox and sc. Both of these would be non-trivial, I imagine, especially 2). Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
