Hello Eric,
Le 24/02/2019 à 13:08, Éric Dubois a écrit :
Hello everybody
I have noticed the same nehaviour with old code that
containded +string(something) the '+' having no left hand side bit of
string.
I think that this an example of a more general approach by recent
Scilab team: make coding more restrictive for the -laudable- goal of
making it more rigourous, This comes however at the price of less
flexibility (I have for example in mind the impossibility with the 6.0
family to have string on several lines ending with '...' to signal
that the string contrinues on next line) and ascending compatibility
for old code (with the risk of losing old users). As we say in French
'le mieux est l'ennemi du bien" (better is the enemy of what is good).
Both aspects are independent.
The implicit support of the unary "plus" /+object/ has been removed for
non-numerical inputs, then routing to the %c_a() overload or inputs like
--> +"abc"
because this support, that on strings did nothing, caused actual issues
: please see the bug 18850
<http://bugzilla.scilab.org/show_bug.cgi?id=15850>, observing that
['x' +'x'] and ['x'+ 'x'] yield ['x' 'x'] , while ['x'+'x'] and ['x' +
'x'] yield ['xx'].
To be silent with such a space sensitivity was not a good think and
generated bugs.
The bug has been discussed and fixed mainly by /contributors/, not by
the Scilab team.
But we are too few. Please join us.
After fixing the bug, the ATOMS GUI was KO. We discovered that this was
due to :
+ "<div>" ..
+ authorHTML
+ "</div>";
From the early ages of the ATOMS GUI, missing dots after authorHTMLwere
not detected, leaving /+ "<div>"/ just as an orphelin, and the built
string was silently incomplete and stayed opened. To what consequences?
Then we scanned the /whole/ native Scilab code against this feature.
Only one another occurrence was found and fixed.
Now, removing suppport to the unary /+string/ does not prevent
re-implementing multiline string continuation. Both considerations are
independent.
There are actual recent cases that more rigor, purism, is really with no
added value and counter-productive. But not for this case.
Anyway, when some decisions have to taken to fix and improve things,
mostly daily, critical constructive, balanced and argued inputs from
users as us are always welcome. We miss them.
Best regards
Samuel
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
