[Scilab-users] unary +"string" removed <= Re: Small problem with Scilab 6.0.1 code generation

[Samuel Gougeon]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190224/ff1de2d7/attachment.htm>