[Scilab-Dev] protect / unprotect: recent progress & analysis
Samuel Gougeon
sgougeon at free.fr
Fri Apr 12 18:40:32 CEST 2019
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.
* One may wish to protect some custom variables in the scilab.ini file.
Please see for instance
o http://mailinglists.scilab.org/Protecting-a-new-variable-by-using-predef-tp4027293.html
o http://mailinglists.scilab.org/Users-fr-Protection-de-variables-tp4037331.html
* When creating a library, one may want and need to provide some
protected constants as members of the library. Please see
o http://mailinglists.scilab.org/problem-defining-protected-functions-in-scilab-tp2615970.html
o http://mailinglists.scilab.org/Library-workaround-wanted-predef-bug-tp4034383.html
* A workaround for libraries existed up to Scilab 5.5, consisting in
including a myConstantes.sci file just setting variables to be
included... and protected, provided that the library is loaded at
startup.
But
1. this worked only for libraries in ATOMS modules loaded at Scilab
startup
2. In files.sci, Scilab 6 genlib() now ignores everything that is
not a function.
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 <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.
>
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.
> * 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 😉
>
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
<http://bugzilla.scilab.org/show_bug.cgi?id=14892>:
--> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20190412/194c2890/attachment.htm>
More information about the dev
mailing list