Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
Kohei Yoshida schrieb: Hi Eike, On Tue, 2008-12-09 at 20:41 +0100, Eike Rathke wrote: 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. It may not be enough to add a mapping in the sc core. In oox there is some postprocessing code executed for each formula which takes care of e.g. missing/unsupported function parameters, add-in/external function handling etc. Would it be an option that the oox module offers the xl formula parser as a special UNO service that implements the com.sun.star.sheet.XFormulaParser interface? So it would be possible for any module to instanciate and use such a parser. 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. I want to keep all filter related stuff in one module, so I think my idea using a service may be a bit better ;-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
Hi Daniel, On Wed, 2008-12-10 at 09:30 +0100, Daniel Rentz wrote: Kohei Yoshida schrieb: Hi Eike, On Tue, 2008-12-09 at 20:41 +0100, Eike Rathke wrote: 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. It may not be enough to add a mapping in the sc core. In oox there is some postprocessing code executed for each formula which takes care of e.g. missing/unsupported function parameters, add-in/external function handling etc. Would it be an option that the oox module offers the xl formula parser as a special UNO service that implements the com.sun.star.sheet.XFormulaParser interface? So it would be possible for any module to instanciate and use such a parser. 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. I want to keep all filter related stuff in one module, so I think my idea using a service may be a bit better ;-) That's definitely a strong option to consider. Thanks for your suggestion. :-) Anyway, for whatever we decide to do to make all this work would definitely take a non-trivial amount of time and effort, so for now, I'll just take out the change I've made (the change that started this whole thread), to keep the xls opcode out of sc. We'll then come back to this at a later time (probably post-3.1) to solve it to make everyone happy. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
On 12/08/08 21:20, Kohei Yoshida wrote: On Mon, 2008-12-08 at 20:43 +0100, Niklas Nebel 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. This is now the second change surfacing from ooxml02 which runs contrary to the separation of filter and core. I hope this doesn't become a trend. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
On Tue, 2008-12-09 at 18:29 +0100, Niklas Nebel wrote: On 12/08/08 21:20, Kohei Yoshida wrote: On Mon, 2008-12-08 at 20:43 +0100, Niklas Nebel 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. 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. I hope this doesn't become a trend. What trend? The change I made was what I believed to be the best move given the existing code structure and what needed to be done. If you have any imaginary trend that you think exists, it's not part of it, whatever that trend may be. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
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. Btw, in the code committed, ScCompiler::InitSymbolsEnglishXL() uses ScGrammar::GRAM_ENGLISH, I think that should had been ScGrammar::GRAM_ENGLISH_XL_A1 instead. 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()? Btw, where is the difference between names VBA uses and names Excel uses in MOOXML? If there isn't any, wouldn't it be natural to share the filter's name mapping with VBA? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpipRKamWw5y.pgp Description: PGP signature
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
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]
[sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
On 12/08/08 19:34, [EMAIL PROTECTED] wrote: Modified: cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl == --- cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl Mon Dec 8 18:33:06 2008(r265029) +++ cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl Mon Dec 8 18:33:13 2008(r265030) @@ -63,6 +63,11 @@ */ const long NATIVE = 3; +/** Function names and operators as used in the English version of +Excel. This formula language is also used in VBA formulas and +OOXML import/export. + */ +const long XL_ENGLISH = 4; }; No, the map of Excel function names is supposed to be part of the Excel filter, and that's how the import already works. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
On 12/08/08 20:17, Kohei Yoshida wrote: On Mon, 2008-12-08 at 20:05 +0100, Niklas Nebel wrote: No, the map of Excel function names is supposed to be part of the Excel filter, and that's how the import already works. But what's the drawback? Defining a formula language here makes it easier to use in the filters as well as VBA formula parsing since it fits nicely in the current grammar framework. To me, not doing this would be a kludge. Again, modularization. We want to separate the Excel filter from the sc module, and opcode mapping is part of it. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
On Mon, 2008-12-08 at 20:43 +0100, Niklas Nebel wrote: On 12/08/08 20:17, Kohei Yoshida wrote: On Mon, 2008-12-08 at 20:05 +0100, Niklas Nebel wrote: No, the map of Excel function names is supposed to be part of the Excel filter, and that's how the import already works. But what's the drawback? Defining a formula language here makes it easier to use in the filters as well as VBA formula parsing since it fits nicely in the current grammar framework. To me, not doing this would be a kludge. 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. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
