<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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://codereview.scilab.org/#/c/20491/">https://codereview.scilab.org/#/c/20491/</a>
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://codereview.scilab.org/#/c/19114/">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>
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>
</body>
</html>