David Burgun wrote:
The reason for this is that around 2 years ago
when I first started using RunRev, I saw an initialization handler
(in one of the Sample Stacks that came with RunRev) that did:
put empty into me
So I used this form from then on and the 99.99% solution got
replicated over and over again!
Right. While your specific setup did manage to discover a bug, perhaps
the reason no one's reported this before is that they prefer to write
less code.
Replicated code not only takes more time to write, but as you note it
takes more time to revise. Even if you were using something that worked
perfectly, there may come a time when you want to enhance it.
Replicated code means replicating the enhancement effort.
In common practice "me" is rarely used, as it only affects one object.
In the example shown above, a more generalized approach might be this
card script:
on preOpenCard
repeat with i = 1 to the number of flds
if the lockText of fld i is false then
put empty into fld i
end if
end repeat
pass preOpenCard
end preOpenCard
That simple handler accomodates any number of fields without
modification to the code or the objects. You can add or delete fields
at any time, and the form still clears itself before being displayed.
Now suppose we later decide we want to have some fields to display
default values, while still leaving others blank. We could add a simple
property to any field that needs it, and we only make a small change in
that one card handler:
on preOpenCard
repeat with i = 1 to the number of flds
if the lockText of fld i is false then
put the uDefaultValue of fld i into fld i
end if
end repeat
pass preOpenCard
end preOpenCard
I read your outline at
<http://lists.runrev.com/pipermail/use-revolution/2006-March/079065.html>,
and although after two readings I can't figure out what its goal is my
hunch is that it could be satisfied with a single backScript or library
and property settings in affected objects.
Such an approach keeps the code centralized, making it easier to write,
maintain, and enhance. Objects could be added or removed from the
behavioral management by just changing a property, never needing to even
open a script editor.
There's also a performance benefit to using the natural message path
whenever practical. Consider these benchmarks from a simple test case*
(times shown are per call):
Native: 0.007ms
Send: 0.011ms
Do: 0.013ms
In a single call, the difference between native message inheritance and
"send" is only 0.004ms, certainly not worth worrying about. But if one
were building a system in which "send" is being used throughout as the
primary means of driving things, the aggregate cost of that 50%
peformance difference may make the system noticeably less responsive.
Those clock cycles could probably be put to better use; even if
performance appears fine for now, future enhancements may require
additional load elsewhere, so it's often a good idea to keep performance
in mind even when it doesn't initially seem important.
There are of course times when "send" and "do" are the only way to solve
a problem, but with the flexibility of frontScripts, libraries, and
backScripts such cases are few.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
* Test scenario:
One stack, one card, one button with this script:
on mouseUp
put 10000 into n
--
put the millisecs into t
repeat n
doMe
end repeat
put (the millisecs - t)/n into t1
--
put the millisecs into t
repeat n
send "doMe" to this cd
end repeat
put (the millisecs - t )/n into t2
--
put the millisecs into t
repeat n
do "doMe"
end repeat
put (the millisecs - t)/n into t3
--
set the numberformat to "0.000"
put "Native: "& t1 &"ms" &cr\
&"Send: "&t2 &"ms" &cr\
&"Do: "&t3 &"ms"
end mouseUp
The card script has this script, just dummy stuff as some arbitrary
thing to do so we don't have an empty handler:
on doMe
get "nothing"
put "nothing" into it
end doMe
Times shown above were on a PowerBook G4 1GHz.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
