Protecting variables



--- Barton Willis <willisb@unk.edu> wrote:

> I like these versions of protect and unprotect better:
> 
> (a) A user can now protect and unprotect several symbols at once.

Nice :-)
 
> (b) This version doesn't error on a non-symbol, instead it prints a
> message.  I think this is better.

Yes, that makes sense.

> (c) Both functions now return true -- previously, they returned
> stuff that a user might think was weird.

Agree - much better.

> (d) Users will need to quote the arguments of protect and unprotect;
> I think this is okay.

Um.  From a usability standpoint, I'm not sure about this one.  Is that
because the argument gets evaluated as the function is called?

> (e) Protect uses a mechanism that is already in Maxima, but mostly
> unused. Because the mechanism is already in the code, I don't think
> using protect should slow Maxima.  A more elaborate protect scheme
> might slow Maxima.

How do you think it would slow it?  The extra checking?

> (f) Some code in /share, for example units.mac, might benefit from
> using protect / unprotect; however, a well-mannered package should
> have code for cleaning house.

Yes.  I think the thing to do in the case of units is to create
defineunits and undefineunits commands as part of the package, which
take care of this automatically.  In the new unit package I was writing
I believe I already have a command to remove unit definitions - it
should be a simple matter to call an internal unprotect command as part
of that operation.
 
I might have made a mistake when I suggested protect should be a more
general function - Richard made some comments that illustrated a
potential can of worms in doing so.  Each package can define their own
scheme that is appropriate for what they want to do.

CY

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/