<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Calibri">Hi Samuel,</font></p>
<br>
<div class="moz-cite-prefix">Le 10/08/2016 à 20:02, Samuel Gougeon a
écrit :<br>
</div>
<blockquote cite="mid:57AB6C27.9000102@free.fr" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hello Pierre-Aimé,<br>
<br>
Le 10/08/2016 17:56, Pierre-Aimé Agnel a écrit :<br>
</div>
<blockquote
cite="mid:db8c8fe7-8ff5-bdc6-888c-20e837cdba01@scilab-enterprises.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p><font face="Calibri">Hello,</font></p>
<p><font face="Calibri">It was changed at resolution of <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bugzilla.scilab.org/show_bug.cgi?id=14316">http://bugzilla.scilab.org/show_bug.cgi?id=14316</a></font></p>
<p><font face="Calibri">I am not sure though whether enforcing
the 'vector ^ scalar' error should be reintroduced. My
2-cents: there are many operations that have the same
behaviour that their dot-operation counterpart when used
with a scalar.<br>
</font></p>
<p><font face="Calibri">I think the operation should remain
available, but I can also enforce the obsolescence in the
release for 6.0.0.</font></p>
</blockquote>
<br>
<font face="Calibri">Thanks for your answer.<br>
I understand that the reversion of the vector^scalar change was
done when fixing #14316,<br>
but as far as i understand, things are not connected. This
reversion was not mandatory to fix #14346.<br>
<br>
IMO, what was planed for Scilab 6 was great. <br>
<br>
I know that this syntax vector^scalar instead of vector.^scalar
was very widespread. But instead of parsing </font><font
face="Calibri">vector^scalar as </font><font face="Calibri">vector.^scalar
as in Scilab <6 or always yielding an error, why not making
Scilab 6 testing whether the overload %s_p_s() (or other%@_p_@()
overload according to operands types) exists. Then, users
wanting to work with the old equivocal behavior could define
deff("r=%s_p_s(a,b)","r=a.^b") in their library (or startup
file) instead of changing all their code. Or/and include their
own warning in their overload whether they wish to actually
upgrade their code. And that's it.<br>
<br>
</font></blockquote>
<font face="Calibri">In my humble opinion, this is a great proposal
that can benefit everyone, we just have to check the already
existing overloads to see if there are any interferences.<br>
<br>
</font>
<blockquote cite="mid:57AB6C27.9000102@free.fr" type="cite"><font
face="Calibri"> Best regards<br>
Samuel<br>
</font><br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Pierre-Aimé Agnel
R&D Projects Manager
Phone: +33.1.80.77.04.67
Mobile: +33.6.82.49.35.23
-----------------------------------------------------------
Scilab Enterprises
143bis rue Yves Le Coz - 78000 Versailles, France
Phone: +33.1.80.77.04.60
<a class="moz-txt-link-freetext" href="http://www.scilab-enterprises.com">http://www.scilab-enterprises.com</a> </pre>
</body>
</html>