Hi Kohei, On Monday, 2008-03-17 21:23:11 -0400, Kohei Yoshida wrote:
> > [... separators at ScAddress::Convention ...] > Well, that code was implemented before ScGrammar arrived in DEV300_m2. > So, I couldn't have used ScGrammar at the time I implemented. Understood. > Of course now that we have ScGrammar I'll be happy to use it instead. > > > [... the separators ...] They should be merged into the SymbolsNative map > > instead. > > Sure. I'll look into that. Thanks. > I have one question, though. Do we still need to differentiate between > the address convention and the formula convention in general? Different address conventions may be used with the same formula language / function names. For example, once we implemented configurable address conventions at the UI, the native formula language could be used with different conventions. For this, additionally to GRAM_NATIVE, I prepared GRAM_NATIVE_UI (used as GRAM_DEFAULT throughout most calls), GRAM_NATIVE_XL_A1 and GRAM_NATIVE_XL_R1C1. They all share FormulaLanguage::NATIVE. See sc/inc/grammar.hxx. Also GRAM_PODF and GRAM_PODF_A1 are identical except the address convention used, with (file format) or without (API compatibility) bracketed references. GRAM_ODFF of course has only one convention, but if needed later GRAM_ODFF_A1 could be used as well, again with the only difference that references wouldn't be enclosed in brackets then. > The idea I envisioned was just to use one global formula convention to > control both the address convention and the rest of the formula > convention (such as the argument and array separators), and expose that > to the UI as well. If I didn't get you wrong that is what ScGrammar effectively does or is prepared for, take a look at the details. It tells the compiler how to parse/stringize. Note that the enum value has room for bits to be used for such things if we had to, the language part is certainly not needed in its full length (kConventionShift). However, I think that because localizable separators would only affect FormulaLanguage::NATIVE (and maybe FormulaLanguage::ENGLISH as well if we wanted to) we simply can store the configured separators in the symbol map and either dynamically adapt the bits in the ScCompiler::pConventions tables according to the current symbol map or setup a localized and UI configured address convention table, and probably have to massage ScCompiler::NextSymbol() somewhat to support that. That's just my quick brainstorm, does it sound feasible? Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks.
pgpBSD6exmbJ7.pgp
Description: PGP signature
