Trap Hilite Command?

[Richard Gaskin]

Mark Schonewille wrote:
> This is impossible, because commands are sent directly to the engine,  
> as Jacque kindly explained a few times. Recently, I tried something  
> similar with a setprop handler, but that didn't work either, even  
> though the compiler accepted it. Still, I would be very interested if  
> you found an elegant workaround. Currently, the only way seems to be  
> to create your own customHilite handler, which hilites the target if  
> not intercepted.

Many years ago I'd inherited a HyperCard project that relied in part on 
overloading built-in commands.  I asked Scott Raney why this wasn't 
supported in Rev (back then it was MetaCard), and he explained about the 
impact allowing that has on performance by increasing the size of the 
token table.

His explanation was appreciated, but still I argued with him on the 
usefulness of overloading and he left me with a challenge:  Come up with 
a case in which it's absolutely necessary, and resulted in better coding 
practices than not, and he'd consider it.  I never did.

But we might possibly have one here.

Scott, if you feel your situation has merit maybe we could thrash it 
around a bit to see if we've found the elusive example?

Now that all major OSes use the same microchip instruction set (Intel), 
I can imagine a world in which true machine-level compilation becomes a 
possibility.  In such a system the size of the token table would have no 
effect on runtime.

Why shouldn't this be explored?

-- 
  Richard Gaskin Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com