[prev in list] [next in list] [prev in thread] [next in thread]
List: scilab-dev
Subject: Re: [Scilab-Dev] type of structs and cells
From: Samuel Gougeon <sgougeon () free ! fr>
Date: 2018-09-12 22:09:39
Message-ID: 1e9eaaad-6a12-143d-e072-80392f8bf638 () free ! fr
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 don't see why. In reading mode, it is possible to retrieve all struct
information in a more direct and handy way:
> --> getfield(1,str)
> ans =
> !st dims a b !
typeof(str) // returns "st" : OK
fieldnames(str) // returns ["a" "b"] : OK
> --> getfield(2,str)
> ans =
> 1 1
size(str) // returns dims values: OK
In addition:
getfield(3, s) // returns the list of values for the "a" field
clear s
s.a = %pi
s(1,2).a = %i
s(1).t = "Hi"
s(2).t = "Bonjour"
*
getfield(3, s)**
// But s(:).a returns the same, without using getfield().
// => So getfield() is now useless for struct()**
**s(:).a**
*
--> getfield(3, s)
ans =
ans(1)
3.1415927
ans(2)
i
--> // But s(:).a returns the same, without using getfield(). So
getfield() is now useless for struct()
--> s(:).a
ans =
ans(1)
3.1415927
ans(2)
i
So: usage of getfield() with structures could and should now be
completely prevented.
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()...
But it is hard to see why it could not be implemented, or at least
reimplemented with setfield(), without reintroducing struct as mlist().
Samuel
[Attachment #5 (text/html)]
<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>
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic