[Scilab-Dev] type of structs and cells

[Samuel Gougeon]

Le 12/09/2018 à 22:08, Stéphane Mottelet a écrit :
>
> Le 12/09/2018 à 21:48, Samuel Gougeon a écrit :
>
>> Hello Stéphane,
>>
>> Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :
>>> Hi all,
>>>
>>> I hope some of you are still reading this list, which has a very low 
>>> traffic these days... I just discovered, while working on
>>>
>>> https://codereview.scilab.org/#/c/20491/
>>>
>>> https://codereview.scilab.org/#/c/19114/
>>>
>>> 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(), 
>>
>> I guess you meant that we must use the typeof() instead of type(). 
>> Anyway,...
>>
>>> 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 ??
>>
>> I had the same question in mind for 2 years. So thanks for asking it 
>> here explicitly!
>>
>> 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.
>>
>> We may imagine that this conservatism is to avoid back-compatibility 
>> issues.
>
> There is more than that. For Scilab 6 structs, for k=1,2 
> getfield(k,...) returns the same result as Scilab 5.5.2
>
> --> str=struct("a",1,"b",1)
>  str  =
>
>   a: [1x1 constant]
>   b: [1x1 constant]
>
>
> --> getfield(1,str)
>  ans  =
>
> !st  dims  a  b  !
>
>
> --> getfield(2,str)
>  ans  =
>
>   1  1
>
> as if str, in this example, was still a mlist. This is so artificial, 
> but certainely necessary !

I must confess that i did not catch how the bug 15034 
<http://bugzilla.scilab.org/show_bug.cgi?id=15034> has been processed.
I feel rather concerned about its processing. It looks to create an
"hybrid/duplicate" type/typeof for struct(), so killing the announcement 
they
are native type in Scilab 6.
To me, AFAIU, this is a confusing and worrying way to fix the bug 15234 
<http://bugzilla.scilab.org/show_bug.cgi?id=15264>.
Unless struct are finally not native at all in Scilab 6. If so, the 
CHANGES file
and the documentation should be fixed to cancel the announcement.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20180912/4122533c/attachment.htm>