<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 12/09/2018 à 22:08, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote cite="mid:7ad98ccb-ae66-18b1-ce6e-e9f62ee67021@utc.fr"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p>Le 12/09/2018 à 21:48, Samuel Gougeon a écrit :<br>
</p>
<blockquote type="cite"
cite="mid:c26d4f73-a731-f429-e476-c37918fb62a9@free.fr">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hello Stéphane,<br>
<br>
Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :<br>
</div>
<blockquote
cite="mid:711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr"
type="cite">Hi all, <br>
<br>
I hope some of you are still reading this list, which has a
very low traffic these days... I just discovered, while
working on <br>
<br>
<a class="moz-txt-link-freetext"
href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20491/"
moz-do-not-send="true">https://codereview.scilab.org/#/c/20491/</a>
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/19114/"
moz-do-not-send="true">https://codereview.scilab.org/#/c/19114/</a>
<br>
<br>
that cells have the same type number, although a different
type string. Hence, when you want to differentiate between
structs, cells, lists, mlists, tlists, you cannot rely on
typeof(), </blockquote>
<br>
I guess you meant that we must use the typeof() instead of
type(). Anyway,...<br>
<br>
<blockquote
cite="mid:711c5235-efd8-0860-a51d-19ec9a6e0eed@utc.fr"
type="cite">since for mlists and tlists they return the
usertype, neither on type(), since it does not make the
difference between cells and structs. I know there exist
isstruct() and iscell(), but why do we have the same type
number ?? <br>
</blockquote>
<br>
I had the same question in mind for 2 years. So thanks for
asking it here explicitly!<br>
<br>
Since in Scilab 6 cells and structs are now native types, it
could have been the opportunity and the right moment to ascribe
a dedicated type() number to each of them, out of their
historical mlist type number 17.<br>
<br>
We may imagine that this conservatism is to avoid
back-compatibility issues.<br>
</blockquote>
<br>
There is more than that. For Scilab 6 structs, for k=1,2
getfield(k,...) returns the same result as Scilab 5.5.2<br>
<br>
--> str=struct("a",1,"b",1)<br>
str = <br>
<br>
a: [1x1 constant]<br>
b: [1x1 constant]<br>
<br>
<br>
--> getfield(1,str)<br>
ans =<br>
<br>
!st dims a b !<br>
<br>
<br>
--> getfield(2,str)<br>
ans =<br>
<br>
1 1<br>
<br>
as if str, in this example, was still a mlist. This is so
artificial, but certainely necessary ! <br>
</blockquote>
<br>
<br>
I don't see why. In reading mode, it is possible to retrieve all
struct information in a more direct and handy way:<br>
<br>
<blockquote type="cite"><tt>--> getfield(1,str)</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt> !st dims a b !</tt><br>
</blockquote>
<br>
typeof(str) // returns "st" : OK<br>
fieldnames(str) // returns ["a" "b"] : OK<br>
<br>
<blockquote type="cite">--> getfield(2,str)<br>
ans =<br>
1 1<br>
</blockquote>
<br>
<tt>size(str) // returns dims values: OK</tt><tt><br>
</tt><br>
In addition:<br>
<font size="-1"><tt>getfield(3, s) // returns the list of values for
the "a" field</tt><tt><br>
</tt><tt><br>
</tt><tt>
</tt><tt>clear s</tt><tt><br>
</tt><tt>s.a = %pi</tt><tt><br>
</tt><tt>s(1,2).a = %i</tt><tt><br>
</tt><tt>s(1).t = "Hi"</tt><tt><br>
</tt><tt>s(2).t = "Bonjour"<br>
</tt><b><tt><br>
getfield(3, s)</tt></b><b><tt><br>
// But s(:).a returns the same, without using getfield().<br>
// => So getfield() is now useless for struct()</tt></b><b><tt><br>
</tt></b><b><tt>s(:).a</tt></b><b><tt><br>
</tt></b><tt><br>
</tt><tt>--> getfield(3, s)</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt> ans(1)</tt><tt><br>
</tt><tt> 3.1415927</tt><tt><br>
</tt><tt><br>
</tt><tt> ans(2)</tt><tt><br>
</tt><tt> i </tt><tt><br>
</tt><tt><br>
</tt><tt>--> // But s(:).a returns the same, without using
getfield(). So getfield() is now useless for struct()</tt><tt><br>
</tt><tt>--> s(:).a</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt> ans(1)</tt><tt><br>
</tt><tt> 3.1415927</tt><tt><br>
</tt><tt><br>
</tt><tt> ans(2)</tt><tt><br>
</tt></font> i <br>
<br>
So: usage of getfield() with structures could and should now be
completely prevented.<br>
<br>
The main issue with new native structures is that, for an array of
structures, it is no longer possible to set the whole set of values
of a field , neither with a .field syntax nor with setfield()...<br>
<br>
But it is hard to see why it could not be implemented, or at least
reimplemented with setfield(), without reintroducing struct as
mlist().<br>
<br>
Samuel<br>
<br>
<br>
</body>
</html>