The default bahaviour of any Basic interpreter should be IMHO to check
the syntax as strictly as possible.
On the other side tons of legacy Basic sources will not compile anymore,
- including the Basic libraries (Access2Base, ...) delivered with LO
unless they're patched on time !
I do support Pierre's proposal to have an option to (temporarily)
*uncheck* the strict syntax checking,
However
- the option should be easily visible and accessible from the Basic IDE
(f.i. not after having checked "enable experimental features" first ...)
- the text of the option should be less cryptic then "StarBasic Pragma
Strict", but preferably something like "Do not check Basic syntax strictly"
- Release Notes and help pages should inform the users in detail
- the option should remain during a long enough period of time
JP
Le 28/06/17 à 13:08, Kaganski Mike a écrit :
On 6/28/2017 2:03 PM, Stephan Bergmann wrote:
On 06/28/2017 12:12 PM, Pierre Lepage wrote:
The solution brings a lot of hassle for customers of the LibreOffice
suite whose work relies on the performance of StarBasic macros written
by third parties. Macros containing code in error by the absence of a
closing parenthesis suddenly cease to function. For this reason, the
patch has not been released. Here I want to explore a transitional
solution by getting your feedback first. This is to include in
StarBasic options dialog accessible to the client a "StarBasic Pragma
Strict" option (checkbox) by which the client consciously activates
the solution (the patch that has not been published!). This check box
would be available for a few years with a warning to prompt
programmers and customers to require their programmer to correct their
default code on the closing parenthesis.
Another option might be to have some form of such a pragma in individual
BASIC source files, instead of as an IDE option. (And have the pragma
enabled in the "REM ***** BASIC ****** Sub Main ... End Sub" boilerplate
that is automatically present in a fresh source file.) That way, users
could enable it for their own, new code, while (implicitly) keeping it
off for non-conforming old, 3rd-party code.
I'd suggest also a special handling of "Compile" IDE command. It should
always use strict parsing method. As it is a developer's tool, used when
something is created anew, it would help all developers catch the
problem early even when they don't know the strict option (wherever it be).
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
