<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello Eric,<br>
<br>
Le 24/02/2019 à 13:08, Éric Dubois a écrit :<br>
</div>
<blockquote
cite="mid:CAGgDjFTFs0=t_K9gLg58HA33QpByxo7cmVZ0Lwo0T2U9tUo-Pg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hello everybody </div>
<div><br>
</div>
I have noticed the same nehaviour with old code that
containded +string(something) the '+' having no left hand side
bit of string.
<div><br>
</div>
<div>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" (<span class="gmail-b2"
style="color:rgb(36,36,36);background-color:rgb(255,254,239);font-family:Arial,sans-serif;font-size:12px">better
i</span><span class="gmail-b3"
style="color:rgb(24,24,24);background-color:rgb(255,252,207);font-family:Arial,sans-serif;font-size:12px">s
the enemy</span><span class="gmail-b2"
style="color:rgb(36,36,36);background-color:rgb(255,254,239);font-family:Arial,sans-serif;font-size:12px"> of
wh</span><span class="gmail-b3"
style="color:rgb(24,24,24);background-color:rgb(255,252,207);font-family:Arial,sans-serif;font-size:12px">at </span><span
class="gmail-b4"
style="color:rgb(12,12,12);background-color:rgb(255,252,207);font-family:Arial,sans-serif;font-size:12px">is</span><span
class="gmail-b3"
style="color:rgb(24,24,24);background-color:rgb(255,252,207);font-family:Arial,sans-serif;font-size:12px"> good).</span></div>
</div>
</blockquote>
<br>
Both aspects are independent.<br>
<br>
The implicit support of the unary "plus" <i>+object</i> has been
removed for non-numerical inputs, then routing to the %c_a()
overload or inputs like<br>
<tt>--> +"abc"</tt><tt><br>
</tt>because this support, that on strings did nothing, caused
actual issues : please see the <a
href="http://bugzilla.scilab.org/show_bug.cgi?id=15850">bug 18850</a>,
observing that<br>
<font size="-1"><tt>['x' +'x'] and ['x'+ 'x'] yield ['x' 'x'] ,
while ['x'+'x'] and ['x' + 'x'] yield ['xx'].</tt><tt><br>
</tt></font>To be silent with such a space sensitivity was not a
good think and generated bugs.<br>
<br>
The bug has been discussed and fixed mainly by <i>contributors</i>,
not by the Scilab team.<br>
But we are too few. Please join us.<br>
After fixing the bug, the ATOMS GUI was KO. We discovered that this
was due to :<br>
<font size="-1"><tt> + "<div>" ..</tt><tt><br>
</tt><tt> + authorHTML</tt><tt><br>
</tt><tt> + "</div>";</tt><tt><br>
</tt></font>From the early ages of the ATOMS GUI, missing dots
after <tt>authorHTML</tt><font size="-1"><tt> </tt></font>were not
detected, leaving <i><tt>+ "<div>"</tt></i> just as an
orphelin, and the built string was silently incomplete and stayed
opened. To what consequences?<br>
<br>
Then we scanned the <i>whole</i> native Scilab code against this
feature. Only one another occurrence was found and fixed.<br>
<br>
Now, removing suppport to the unary <i>+string</i> does not prevent
re-implementing multiline string continuation. Both considerations
are independent.<br>
<br>
There are actual recent cases that more rigor, purism, is really
with no added value and counter-productive. But not for this case.<br>
<br>
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.<br>
<br>
Best regards<br>
Samuel<br>
<br>
</body>
</html>