Privatizing Custom Properties - Cool

Dan Shafer dan at danshafer.com
Thu Aug 1 01: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