Access2Base - New release

Noel Power nopower at
Mon May 19 03:06:46 PDT 2014

On 19/05/14 08:23, Stephan Bergmann wrote:
> On 05/16/2014 06:39 PM, Lionel Elie Mamane wrote:
>> So, the question is "why does this code enforce this condition, and
>> can we change it"? Can we just remove the condition altogether, or
>> should we add this case:
>>                  || sOriginalUrl.match("$(INST)")
>> Noel? Uray? You are our Basic "FindTheExpert"s. What's your opinion on
>> this?
So I wasn't following this, I was away for the last week anyway and
while reverse scanning my mail I stumbled on this. It seems to me that
the code there (which I admit I am not familiar with) is all to do with
extensions and management of extensions right? In this case you are
talking about trying to override a built-in library with an extension,
the code it would seem rightly tries to prevent an extension from doing
that. I mean there are wizards, conversions, routines etc. that are
considered part of the system that shouldn't be 'replaced' under the
hood.  Access2Base is considered a part of the core isn't it? it isn't
shipped as an extention, it is shipped as part of the product, it seems
to me that you are trying to get around the rules of no-new features
etc. by exploiting the extension mechanism. Access2Base is either part
of the product or it's not. Also doesn't the code mentioned above
actually try and remove the existing library? perhaps the
librarycontainer does something special in this case, I don't know.
But.... in anycase although Access2Base is part of the core, part of the
product etc. it is afaik completely selfcontained (and essentially a
separately maintained subsystem) in this case I think there is a good
argument to bend the rules regarding updating the version of Access2Base
shipped, we already do that occasionly I think?
> Most likely, the reason that that desktop/source/deployment code only
> checks against existing extension libraries but not built-in ones is
> that that was never a use-case the code was designed for.  I do not
> know, though,whether there are any gotchas on the BASIC side that
> would be enabled by your proposed change.
<shrug> I'm not sure, I know any duplicate symbols (and it can happen in
libreoffice basic) can cause unexpected and suprising results, imho they
shouldn't be allowed but that's another story. I'm still not sure what
actually happens when such a scenario as above is forced, is the 'old'
library removed or not, if not does the 'old' library actually get
compiled even, what happens later when upgrading, does it set a
precedent for binary extensions to be able to replace 'system'
components (if that isn't already possible) etc.


More information about the LibreOffice mailing list