protect / unprotect: recent progress & analysis

classic Classic list List threaded Threaded
4 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

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?

  • 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Antoine Elias-3 Antoine Elias-3
Reply | Threaded
Open this post in threaded view
|

Re: protect / unprotect: recent progress & analysis

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 <[hidden email]>
Envoyé : dimanche 7 avril 2019 19:25
À : Antoine Elias <[hidden email]>; List dedicated to development questions <[hidden email]>
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.

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.


 


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: protect / unprotect: recent progress & analysis

Hello Antoine,

Le 09/04/2019 à 09:52, Antoine Elias a écrit :

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.


uman predef @
displays a first list of threads about this topic.

A short list of bugs/wishes reported on Bugzilla has been published here:
http://mailinglists.scilab.org/Scilab-users-Replacing-predef-with-an-actual-varprot-a-top-5-priority-for-Scilab-6-1-At-last-protecte-tp4036564.html
with some comment about sharing the need for variables protection.

So, a priori the need applies to any variables type, including libraries.

Another user case:
You are a teacher, and you prepare some Scilab materials -- scripts.sce, etc -- for a practical session with some work to do with Scilab. When newbies students work with your script, they do really many things, and often some unexpected ones, as overwriting some variables predefined in the script, etc. If you don't want to spend your time during the session to debug the results of their freedom instead of focusing on the topic of the session, protecting predefined variables is expected to help a lot...

My first message does not aim to tell all what should be done, but to tell what we -- devs and users -- should be aware of when designing, then documenting, and finally using the protection of variables, as well with respect to existing features : funcprot(), predef(), clear, scope management of variables, global, clearglobal.

 

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


To me, protecting global variables is not needed. I mean, in the global storage. The main threat are clear() instructions loved by a subset of Scilabers. clearglobal() is likely much less used.

But, as far as i understand, global works with a local "copy", that could be protected as a local variable. There is no reason to prevent this, but it must be clearly stated that such a protection won't apply to the global counterpart. Example:

--> global a
--> a = 1;
--> clear a
--> a
Undefined variable: a

--> global a
--> a  // we locally retrieve a copy of the global instance
 a  =
   1.
--> clear a
--> a = 3   // only local
 a  =
   3.
--> // protect a
--> global a
--> a      // the global content overwrites the local one
 
a  =
   1.

Now, if we uncomment the // protect a  instruction, what will be expected?
The priority between global and the local protection will have to be clarified and documented.


 

Look Answers/Questions in blue in your message

My replies in magenta:

 

Regards,

Antoine

De : Samuel Gougeon [hidden email]
Envoyé : dimanche 7 avril 2019 19:25
À : Antoine Elias [hidden email]; List dedicated to development questions [hidden email]
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.

Samuel: I think that returning a matrix of booleans indicating the actual new status of variables might be useful, indeed.


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

Samuel: I don't think there should be a special mechanism for them. But as listed below, protection levels might be defined.

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 😉

Samuel: This sounds reasonable. But this could yield an error instead of silently leaving.

 

 

Antoine: funcprot defines a global behavior for redefinition of functions, that's not exactly the same scope.

Samuel: Indeed, in 5.5.2, functions look somewhat "global":
-->function test()
-->    linspace = 1;
-->endfunction
-->test()

Warning : redefining function: linspace   . Use funcprot(0) to avoid this message

It is no longer the case in 6.0:
--> funcprot()
 ans  =
   1.
--> function test()

  >     linspace = 1;
  > endfunction
--> test()
-->


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.

Samuel: clearly, if some "class protection" is implemented and enabled in addition to some object protection, funcprot() would have to be deprecated and removed.

Now, the question is: is a general class protection actually needed?
For all data types: likely not. For libraries: i don't think so. But other contributions to this discussion would be welcome.
Reverse question: If funcprot() is kept, will protect() will apply to functions as well, or will be excluded? If it applies to them, how will this cope with funcprot()?

Regards
Samuel

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: protect / unprotect: recent progress & analysis

Le 12/04/2019 à 18:40, Samuel Gougeon a écrit :
.../...

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.

Samuel: clearly, if some "class protection" is implemented and enabled in addition to some object protection, funcprot() would have to be deprecated and removed.

Now, the question is: is a general class protection actually needed?
For all data types: likely not. For libraries: i don't think so. But other contributions to this discussion would be welcome.
Reverse question: If funcprot() is kept, will protect() will apply to functions as well, or will be excluded? If it applies to them, how will this cope with funcprot()?

Because presently funcprot() does not prevent silently clearing a function, it looks unrelevant to extend its mechanism to some other data types. But
  • would it be hard to change this behavior: warning or yielding an error as well when a function is cleared?
  • Then, would it be hard to extend the changed behavior to any given data type?
Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev