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

[Samuel Gougeon]

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.





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