Privatizing Custom Properties - Cool

Jan Schenkel janschenkel at yahoo.com
Thu Aug 1 03:30:01 CDT 2002


Hi Dan,

I see your plan, and it is interesting.
The main thing I've used setProp / getProp for so far,
was to easily protect the consistency of an object by
patching the property's setProp to also change other
properties -- though another tactic is to switch the
active propertySet, especially if you're working with
predefined combinations.
But this is an intresting extra in the arsenal.

Thanks for the info,

Jan Schenkel.

"As we grow older, we grow both wiser and more foolish
at the same time."  (De Rochefoucald)

--- Dan Shafer <dan at danshafer.com> wrote:
> 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
>
http://lists.runrev.com/mailman/listinfo/use-revolution


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com



More information about the use-livecode mailing list