My reply is: Self-modifying code should be forbidden by law, I really though we got over that about 20 years ago ;-)
And: Decoding bytecode is not necessary, if the byte code is precompiled code (like in JAVA or PHP, which uses precompiled "twostep" code to speed up things). Doing a full interpretation of plain text really will be the slower solution compared to bytecode. I wasn't only thinking of "encryption" here but also of safety, performance etc.
The more "data" has to be loaded the less CPU cache can be used to actually EXECUTE the code. I was used to calculate CPU cycles to make the best of my code, so again this may just be my (wrong) development background :-)
Hah! Yes, self-modifying code is frightening in many respects. But it should be noted than in standalones, there is a serious limitation: the "do" statement and setting of script properties is subject to a 10-line limit. Also don't forget that most interpreted languages have the equivalent of "do", so they have the same potential hole.
Don't forget that without a 3rd party accelerator (or a "1st party" accelerator if you count those Zend weasels!), PHP is actually re-compiled for every execution. Granted, many people use an accelerator product.
In theory you are correct that re-interpreting source code must take extra time, but in practice I think you will be very pleased if you compare Transcript performance to that of Java. GUI runs much faster (and is at least as cross-platform, albeit outside the browser), string handling is light years faster, even graphics and math stack up pretty well, although you might be able to dig deep depending on your Java platform, skills, etc.
- Brian
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
