[Scilab-Dev] protect / unprotect: recent progress & analysis

[Antoine Elias]

Hello Samuel,

Just a question what is the goal of this feature ?
Because after more than 10 years on Scilab, I never need this, so I need your help to understand needs and cases.

Currently, un/protect is only on local variables not on global. ( but that could change if needed )

Look Answers/Questions in blue in your message

Regards,
Antoine
De : Samuel Gougeon <sgougeon at free.fr>
Envoyé : dimanche 7 avril 2019 19:25
À : Antoine Elias <Antoine.Elias at esi-group.com>; List dedicated to development questions <dev at lists.scilab.org>
Objet : protect / unprotect: recent progress & analysis


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?
Antoine: Currently nothing, do you have any request ?
I can return status of un/protect and %f for non-existing variable.

  *   Do we have
assert_checkequal(size(isprotected(["a", "b", "c"])), [1 3])
Antoine: Yep

  *   Will current "permanent variables" be protected with protect() or with another special protection?
unprotect %inf  // => error ?
// IMO, one should avoid keeping concurrent protection features.
Antoine: Current protection of predefined variable ( %pi, %inf, %nan, %e, … ) is done by the same feature.
I don't know if we should forbidden unprotect of predefined variables.

  *   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
Antoine: Clearly, I don't know 😉
Who is the strongest between local protection or clearglobal ?

  *   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 ?
Antoine: When leaving a function, ALL local variables are deleted regardless their protection.
Why ? Because we don't know where to put them 😉


Antoine: funcprot defines a global behavior for redefinition of functions, that's not exactly the same scope.
Maybe we can include functions in un/protect feature but what to do with funcprot ?
I think it will be difficult to keep both and that will be puzzling for users.

  *   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.



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