[Next] [Previous] [Up] [Top]
4 Using the Cecil Evaluator
The ability to add or redefine methods is one of the key features of the evaluator. However, there are some situations in which it does not work. Runtime extension methods (methods declared as part of a session with the evaluator) are implemented by interposing on the dynamic dispatching mechanism. Therefore if a message send is either inlined or statically bound (and thus does not go through the dynamic dispatching mechanism), then no runtime extension method is invoked. With some knowledge of the optimizations performed by the compiler, it is possible to predict whether a particular call-site will be dynamically dispatched, and thus a call-site at which a runtime extension method could be invoked. However, it is likely that a casual user will not want to figure this out. A simple rule is that if a call-site is located in a file which was compiled without optimization, then the call-site will be dynamically dispatched and thus runtime extension methods will perform as expected. Alternatively, if a file includes the (**debug**) pragma, then all methods in that file can be replaced by a runtime extension method (i.e., all calls to the methods defined in the file will be forced to be dynamically-dispatched). Individual methods can also be annotated (**debug**) as follows:
method testing(x@:int, y:string) (** debug **) { method_body }
Runtime extension methods only persist for as long as the program is running. If you add a method to a program, and then exit the program and restart it, the new method will not be present. Runtime extension methods are not saved in Vortex checkpoint files.
How to Use the Vortex Compiler - 20 JAN 97
[Next] [Previous] [Up] [Top]