[Scilab-Dev] type of structs and cells

[Stéphane Mottelet]

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 !
> However, when we look for the "*17*" pattern in the whole native *.sci 
> Scilab files, we get only *85 possibly relevant hits in 58 files* 
> (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml), over thousands 
> of files.
> The full list is attached.
>
> 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 
> "*[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]*" is very simple, 
> to get on the spots and update relevant occurrences.
>
> So, to me, ascribing dedicated and separate type() numbers to cells 
> and structures is still a relevant question, for Scilab 6.1.
> Scilab 6 aims to be more consistent. Ascribing new type codes to now 
> native cells and structures looks possible at low cost.
>
> Best regards
> Samuel
>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev

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