<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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=utf-8" 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 type="cite"
cite="mid:c26d4f73-a731-f429-e476-c37918fb62a9@free.fr"> However,
when we look for the "<b>17</b>" pattern in the whole native *.sci
Scilab files, we get only <b>85 possibly relevant hits in 58
files</b> (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml),
over thousands of files.<br>
The full list is attached.<br>
<br>
This is much fewer than for some other features removed from 5.5
for 6.0. By the way, contrarily to a syntactic change like []+n
that can't be tracked in the code, parsing any external user code
for "<b>[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]</b>"
is very simple, to get on the spots and update relevant
occurrences.<br>
<br>
So, to me, ascribing dedicated and separate type() numbers to
cells and structures is still a relevant question, for Scilab 6.1.<br>
Scilab 6 aims to be more consistent. Ascribing new type codes to
now native cells and structures looks possible at low cost.<br>
<br>
Best regards<br>
Samuel<br>
<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="https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev">https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
</body>
</html>