Calc function names saved to file and backward compatibility

Eike Rathke erack at redhat.com
Mon Feb 16 12:47:26 PST 2015


Hi Winfried,

On Thursday, 2015-02-12 11:22:04 +0100, Winfried Donkers wrote:

> In Calc, the current situation is:
> Calc UI    ODF                      Excel
> FDIST      LEGACY.FDIST             FDIST
> F.DIST     COM.MICROSOFT.F.DIST     _xlfn.F.DIST
> F.DIST.RT  COM.MICROSOFT.F.DIST.RT  _xlfn.F.DIST.RT
> (ODF's FDIST is not used)
> 
> I think the desired situation is:
> Calc UI    ODF                     Excel
> FDIST      COM.MICROSOFT.FDIST     FDIST

No, the UI FDIST is actually the ODF LEGACY.FDIST which was specified
after those implementations.

> F.DIST     FDIST                   _xlfn.F.DIST     
> F.DIST.RT  LEGACY.FDIST            _xlfn.F.DIST.RT
> (in case of UI's F.DIST, on export to Excel add argument cum=true, if absent)

Correct, I think (if the F.DIST.RT is actually the LEGACY.FDIST,
I didn't check now).


> These F-distribution functions are not unique having this problem, at least (ISO)WEEKNUM (tdf#50950) and probably other distribution functions share this.

Actually this one is easier, as it involves only some renaming of
function names written to files, not functionality or changes in
parameters and add-in vs. built-in function.

> I think an agreed method should be used to fix these problems, with the method to be determined (or is the method already defined?).

In practice yes, in theory no ;-)
I still wanted to have that written that down somewhere. IIRC I even
created almost empty wiki pages but then got distracted.. have to
retrieve them again.

What we usually do is add a compatibility name to older release branches
so the next release there can read both, the new name and the old name,
but continues to write the old name so earlier releases of the same
(usually two) branches are not affected.

Then for the next release branch (now master) switch from writing the
old name to writing the new name, but still accept the old name
"forever".

You can find examples of that in sc/source/core/tool/compiler.cxx
ScCompiler::IsOpCode() in aOdffAliases.

So for older release branches you'd add FDIST with ocFDist_LT there, and
in master you'd add COM.MICROSOFT.F.DIST with ocFDist_LT and in
formula/source/core/resource/core_resource.src section
RID_STRLIST_FUNCTION_NAMES_ENGLISH_ODFF replace COM.MICROSOFT.F.DIST
with FDIST for SC_OPCODE_F_DIST_LT.

> AKAICS, this method ranges from one code change (breaking compatibility with older versions and documents), via stepped code changes (maintaining compatibility for e.g. 2 Lo versions) to (but excluding) not changing anything.

It's maintaining compatibility for the last two release branches.
We did the same for erroneously written ODF attributes btw.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150216/2688f1e5/attachment.sig>


More information about the LibreOffice mailing list