Mat Korica asks:
> So how do the standard object-oriented programming concepts translate into
> the Rev world? How do I make classes, subclasses, instances, etc.
Traditional OOP per se is not easily done in an xTalk. There are common
elements between xTalk and OOP systems, but each model has unique strengths
and weaknesses which offer different ranges of benefits for the job at hand.
I have hobbyist interest in automata and simulations, where OOP is
particularly useful. I crafted a couple of tests for a framework that will
give me enough OOP-like behavior to get the job done and still keep the code
simple. It's nothing fancy, little more than a slightly slower verion of
the parentScript feature I keep requesting, but might be useful:
I have a stack named "Classes" that contains a bunch of buttons. The
scripts of all buttons in the Classes stack are inserted as backcripts on
startup.
The script of each Class button has handlers that take this form:
<nameofclassbutton>.<messagename>
e.g.,
cFieldClass.mouseUp
cDataEntryClass.closeField
The system has a frontscript that traps most system messages, and checks the
target for a custom property named "Class". We can call this the
Dispatcher. If the target has a Class property the Dispatcher simply
prepends it to the name of the message and sends that to the target.
For example, suppose you click on a button. The Dispatcher gets the message
first with this trap:
on mouseUp
doClass the params
pass mouseUp
end mouseUp
The doClass handler is also in that frontscript:
on doClass
get the Class of the target
if it is not empty then
if there is not a btn it of stack "classes" then exit doClass
put the params into tParams
delete word 1 of tParams
delete char 1 of tParams
delete last char of tParams
put cr&"on "&it&"."&word 1 of tParams into tCheckStr
if tCheckStr is in the script of btn it of stack "classes" then
send it&"."&tParams to the target
end if
end if
end doClass
The resulting "cFileSelector.mouseUp" message is sent to the target, and
since the target doesn't handle it directly it passes through to the class
definition for cFileSelector, which is the backscript for the button of that
name from the Classes window:
on cFileSelector.mouseUp
answer file "Select a file:"
if it is empty then exit to top
set the uFile of the target to it
end cFileSelector.mouseUp
While this message heirarchy scheme is only one-deep, it's relatively fast
and allows you an easy way to handle messages for a great many objects
without ever putting any scripts in any of them. You just set one property,
and their behaviors change.
To measure performance, I modified the Dispatcher's doClass handler to
measure speed:
on doClass
put the milliseconds into t
repeat 1000
get the class of the target
if it is not empty then
if there is not a btn it of stack "classes" then exit doClass
put the params into tParams
delete word 1 of tParams
delete char 1 of tParams
delete last char of tParams
put cr&"on "&it&"."&word 1 of tParams into tCheckStr
if tCheckStr is in the script of btn it of stack "classes" then
send it&"."&tParams to the target
end if
end if
end repeat
put (the milliseconds - t) /1000 && the params
end doClass
On my G4/500, and using only stub handlers in the button class so as not to
muddy the waters, it seems the Dispatcher takes about 1/10 of a millisecond
to execute (0.096 ms avg). Noticeable difference, esp. since most messages
are simply passed without processing, as only those messages handled by the
target's class ever get dispatched.
--
Richard Gaskin
Fourth World Media Corporation
Custom Software and Web Development for All Major Platforms
Developer of WebMerge 1.9: Publish any Database on Any Site
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
Tel: 323-225-3717 AIM: FourthWorldInc
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
