Privatizing Custom Properties - Cool
Dan Shafer
dan at danshafer.com
Wed Jul 31 21:52:01 EDT 2002
I haven't seen anything written about this and because of my
background in Smalltalk where you can protect variables from external
access quite neatly, I was impressed with RR's ability to let me do
this.
FWIW.
There are two constructs in RR that aren't well documented: getProp
and setProp. Their syntax is a little bizarre, but they are
potentially quite useful. They offer interesting ways of protecting
data from prying eyes.
Let's assume you have a custom stack property called propertyLocker.
You set its value to "true" on openStack and it's important that it
not be changed later except by a script unless someone with proper
access authorization clicks on a button to do so.
In the stack script, you have two handlers:
on openStack
set the propertyLocker of this stack to "true"
end openStack
setProp propertyLocker, spam
global theMethod
if theMethod is "button" then
answer "Sorry, that property is not publicly settable" with "OK"
else
pass propertyLocker
end if
end propertyLocker,
Here, I simplified the process a bit by having an attempt to set the
custom property's value by clicking on a button which defines and
sets a global variable called "theMethod" to "button." You could
obviously use a lot of other tricks and techniques here. And instead
of an absolute lock-out as I have implemented it here, it would
obviously be easy to do a password-protect at this point as well.
Now the mouseUp handler for the button that allows an authorized user
to change the value of the custom property would perhaps look like
this:
on mouseUp
global theMethod
put "button" into theMethod
set the propertyLocker of this stack to "false"
end mouseUp
The thing that's a little strange, syntactically, is the setProp
handler. The docs define this as a "construct" rather than a handler
and it doesn't use the "on" syntax of a message handler. Notice that
you have to supply a second argument, which I've called (creatively
enough) "spam" (my favorite programming language is not Transcript,
alas, but Python...'nuf said).
Notice, too, that the "pass" doesn't pass "setProp" as might expect
but rather the name of the property whose setProp construct is
involved. In this case, that's propertyLocker. Finally, check out the
"end" line; the comma there is mandatory. leave it out and you find
yourself in Bugsville.
You can use setProp's sibling getProp to protect a custom property
from being read or displayed. The same basic syntax and approach
apply.
I am going to experiment with these cute little constructs to see if
I can implement a fairly reusable protocol that would require scripts
that wish to access custom properties of certain objects to do so
only through a script interface (what we in Smalltalk would call
getters and setters or get/set methods) rather than by direct access
to the property. This has the design advantage that you can change
the type of data stored in the custom property and not break any code.
Enough late-night ramblings. Likely only a very few of you will find
this of more than passing interest, but there you have it!
--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
http://www.danshafer.com
831-392-1127 Voice - 831-401-2531 Fax
More information about the use-livecode
mailing list