<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello Antoine,</p>
<p>On 2019-01-18, you called in a private mail for comments about
the <br>
initial implementation of some variables protect / unprotect
features<br>
commited @ <a class="moz-txt-link-freetext" href="https://codereview.scilab.org/20712">https://codereview.scilab.org/20712</a></p>
<p>First of all, thanks a lot for the implementation progress about
this long-wished feature.<br>
Excellent news.<br>
<br>
After your call, please find below some (sometime naive) remarks
and questions about the initial commit, mainly about the expected
behavior of the features.<br>
<br>
As a contribution to the features analysis,<br>
<br>
Best regards<br>
Samuel<br>
</p>
<ul>
<li>Do protect() and unprotect() return anything?<br>
<br>
</li>
<li>Do we have<br>
assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3])<br>
<br>
</li>
<li>Will current "permanent variables" be protected with protect()
or with another special protection?<br>
unprotect %inf // => error ?<br>
// IMO, one should avoid keeping concurrent protection features.<br>
<br>
</li>
<li>Protection of global variables: What will happen or is
expected in the following cases, from the top level (console)?<br>
global a<br>
protect a<br>
clear a<br>
clearglobal a<br>
// See also: <a class="moz-txt-link-freetext" href="http://bugzilla.scilab.org/15250">http://bugzilla.scilab.org/15250</a><br>
// <a class="moz-txt-link-freetext" href="http://bugzilla.scilab.org/14928">http://bugzilla.scilab.org/14928</a><br>
<br>
</li>
<li>Protection and scope:<br>
When protecting a variable in a function, what will happen when
leaving the function?<br>
a = 1;<br>
b = 2;<br>
function r = test(g)<br>
disp(isprotected("g")) <br>
// Is the protection status of a variable as input argument
heritated by the passed copy?<br>
// I guess that no, but this should be clearly stated and
tested.<br>
a = a, protect a<br>
global b, protect b<br>
c = %pi/%e;<br>
r = c;<br>
protect c r<br>
endfunction<br>
e = 3; protect e<br>
d = test(e); // Do we get an error due to deletion of
protected internal c ?<br>
isprotected("a") // => %F : protect a // just protects the
local copie, doesn't it?<br>
isprotected("b") // => %T | %F ?<br>
isprotected("d") // => %T | %F ?<br>
<br>
</li>
<li>Will funcprot() be kept? If yes, how will it cope with the new
protect/unprotect feature?<br>
funcprot(2);<br>
unprotect linspace // => error ?<br>
linspace = 1; // => error ?<br>
<br>
// Conversely:<br>
funcprot(0)<br>
function test(), a=1; endfunction<br>
protect test<br>
test = 3; // => error ?<br>
<br>
</li>
<li>class protection: in order to replace funcprot(), we could
imagine a "class protection" more general than only for Scilab
functions: each time that a new object of type 13 (or #n) or of
typeof "function" (or whatever) is created, a given protection
status is automatically ascribed to it.<br>
protect("-type", 13) // <=> funcprot(2)<br>
unprotect("-type", 13) // <=> funcprot(0)<br>
protect("-type", 14) // <=> as a libprot<br>
<br>
</li>
<li>Protection level: As with the current funcprot()
implementation, we may imagine transfering to the new protect()
function the 3-status possibility: unprotected / warnable /
protected.<br>
Then, unprotect() becomes useless. It is replaced with<br>
protect(0, ["a" "b" "cd"])<br>
// in addition to<br>
protect(1, ["a" "b" "cd"])<br>
protect(2, ["a" "b" "cd"])<br>
<br>
To stay console-oriented, the 0|1|2 status could also be figures
"0"|"1"|"2", provided that no Scilab variable name can start
with a 0-9 figure.<br>
To me, even without "warnable" status, these syntaxes would be
preferable, avoiding a useless unprotect() interface while the
job is basically the same. Just the value to ascribe to the new
status is changed. This requires an additional input arg, not a
specific function. Scilab is not a low-level language.<br>
<br>
<br>
<br>
</li>
</ul>
<br>
<font face="Arial"><br>
</font>
</body>
</html>