Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


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.

Noel

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.