Ben Rubinstein wrote:
> Richard Gaskin wrote:
>> I went to the mat with him over this one years ago when I was
>> porting an HC project. He said, "If you need a custom behavior,
>> use a custom name." I said, "But I *need* to override the
>> built-in function!" and he asked simply, "'Need'? Why?" I
>> couldn't think of a truly necessary case.
>
> "Truly necessary" is never going to be a really objective measure,
> and hence is not an easy threshold to meet.
True, and it may actually be impossible to meet, at least in a purely
logical sense. In law, civil cases have the lower threshold of
"preponderance of evidence", while criminal cases use "beyond a
reasonable doubt". But even criminal cases don't require absolute
proof. The closer a logical threshold approaches an absolute, the less
likely it is that it can be satisfied.
While he was fond of terse phrases like that, in practice my discussions
with Raney about languages features were guided by a more pragmatic
principle: "Is it worth it?"
Most things in computing involve trade-offs, often of memory vs. speed,
and in the case of supporting all of HypeTalk's options it's more of
flexibility vs. speed.
Rebecca Bettencourt recently shared this valid HyperTalk example on the
HC list:
put empty into a
put "a b c" into item
put 1 into char
put 2 into word
if true then repeat with word char of item = char char to word of word
char of char to word char to char of char char of word
answer a&&"HyperTalk is a bitch to parse
end repeat else beep
She also included this note with it:
[The fifth line (if true then repeat with...) is really long and
may need to be unwrapped. The sixth line (answer a...) has no
ending quote, but have no fear.]
No ending quote? Hmmm....seems odd to me, but I trust her judgment here
as she has far more experience finding the boundaries of HyperCard's
interpreter than I do.
To fully support HyperTalk would require allowing syntax like that to
compile and execute. For myself, and perhaps Dr. Raney, I don't see
that as a desirable goal at all, even without taking into account the
impact it has on execution speed.
But once we consider how much faster an engine can be once the parser is
pruned down to expressions that are more valuable, it seems an even
simpler choice to just say no, moving the gun so that it no longer
points at the programmer's foot to a more useful target.
With overriding built-in functions, I agree with his edict that "if you
need a custom behavior, give it a custom name". It just makes the code
more transparent; I've hated doing maintenance on someone else's code
where they overrode built-in behaviors in ways that were concealed from
the reader. Using custom names for custom behaviors makes it
self-evident that it's custom, right in the context where it's called,
without having to do a search across the code base to see if an
overriding handler may exist.
With using built-in tokens as variables, Ms. Bettencourt's exaample
illustrates everything we might want to say. :)
With chunk order, requiring parentheses not only allows Rev to handle
many of the expressions we might enjoy in HyperTalk, but also helps
guide the eye when skimming code.
I'll admit I'm a bit fond of parens and use them where they aren't even
necessary, in things like:
if ("dev" is in the environment) AND (the optionKey is "down") then
Parens can aid skimming. Code is far more frequently skimmed than read,
so anything that helps the eye move quickly to what it's looking for is
valuable two years later when you need to go back to enhance a feature.
Sure, these are all limitations, restrictions over what was originally
implemented in HyperTalk.
But when we ask, "Is it worth it?", just benchmark compatible scripts in
both HC and Rev: Aside from a very few specific actions (HC's patented
search algorithm is hard for anyone to beat), Rev's performance is often
faster. And not just two times or three times faster, but in some cases
by orders of magnitude.
> ... a simple statement, legal in the syntax, which crashed Rev
> with 100% reliability shouldn't be marked "critical" because
> it could only affect the programmer, who should know better.
What statement is that, and has it been fixed?
> So I'm not suggesting any of the following would have got you off
> the mat. However, here's a couple of cases:
>
> * Relating to a recent discussion: I'd quite like my IDE extensions
> to override "answer" with a version that always had a special
>'emergency exit' control, which would cause it to exit to top in
> the thread that invoked answer.
Agreed on it's usefulness, but overriding the answer command seems a
workaround to a deeper issue: "exit to top" isn't honored when called
from within any modal dialog.
<http://quality.runrev.com/qacenter/show_bug.cgi?id=294>
If we address that root issue and added support for Cmd-. to invoke it
in that dialog (at least within the IDE), the "answer" command itself
would be fine.
> * RevBrowser responds to a javascript alert in the hosted page by
> invoking 'answer'. I'd really like to trap this - currently I can't
> see any way to do so. If I could override "answer", I'd have a
> method.
Custom-handling the JS alert sounds very valuable indeed, and while I
haven't done much with RevBrowser thus far I will be later this year and
may need that myself.
I wonder if this might be handled well with a property, maybe something
like "the JSAlert", which would let you assign any command in your
stacks to handle JavaScript alerts. If left empty, the current behavior
would remain.
Do you have a RQCC request for this?
> ...but really I'm playing devil's advocate: I'm very happy with the
> trade-offs Scott Raney made that give us blazing speed.
Amen, brother. I loved it when C++ Journal wrote a review of my
Rev-build WebMerge app in which they mistakenly said it was written in
C. :) I wish I could take credit for that, but its performance has more
to do with Raney pruning the token table than my scripts.
--
Richard Gaskin
Fourth World
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
