Hello Antoine,
On 2019-01-18, you called in a private mail for comments about the
initial implementation of some variables protect / unprotect features
commited @ https://codereview.scilab.org/20712
First of all, thanks a lot for the implementation progress about this
long-wished feature.
Excellent news.
After your call, please find below some (sometime naive) remarks and
questions about the initial commit, mainly about the expected behavior
of the features.
As a contribution to the features analysis,
Best regards
Samuel
* Do protect() and unprotect() return anything?
* Do we have
assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3])
* Will current "permanent variables" be protected with protect() or
with another special protection?
unprotect %inf // => error ?
// IMO, one should avoid keeping concurrent protection features.
* Protection of global variables: What will happen or is expected in
the following cases, from the top level (console)?
global a
protect a
clear a
clearglobal a
// See also: http://bugzilla.scilab.org/15250
// http://bugzilla.scilab.org/14928
* Protection and scope:
When protecting a variable in a function, what will happen when
leaving the function?
a = 1;
b = 2;
function r = test(g)
disp(isprotected("g"))
// Is the protection status of a variable as input argument
heritated by the passed copy?
// I guess that no, but this should be clearly stated and tested.
a = a, protect a
global b, protect b
c = %pi/%e;
r = c;
protect c r
endfunction
e = 3; protect e
d = test(e); // Do we get an error due to deletion of
protected internal c ?
isprotected("a") // => %F : protect a // just protects the local
copie, doesn't it?
isprotected("b") // => %T | %F ?
isprotected("d") // => %T | %F ?
* Will funcprot() be kept? If yes, how will it cope with the new
protect/unprotect feature?
funcprot(2);
unprotect linspace // => error ?
linspace = 1; // => error ?
// Conversely:
funcprot(0)
function test(), a=1; endfunction
protect test
test = 3; // => error ?
* 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.
protect("-type", 13) // <=> funcprot(2)
unprotect("-type", 13) // <=> funcprot(0)
protect("-type", 14) // <=> as a libprot
* Protection level: As with the current funcprot() implementation, we
may imagine transfering to the new protect() function the 3-status
possibility: unprotected / warnable / protected.
Then, unprotect() becomes useless. It is replaced with
protect(0, ["a" "b" "cd"])
// in addition to
protect(1, ["a" "b" "cd"])
protect(2, ["a" "b" "cd"])
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.
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.
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
