BRiX
Advanced Computing Environment
Hosted by SourceForge
brix-os project page

Previous: Identifiers, Objects and References ----- Up: Contents ----- Next: Garbage Collector

Static and Dynamic Typing

When identifiers are not annotated with types the compiler will look at the data assigned to it and determine the best possible type. If enough supporting type information is available the compiler will make an exact guess and static code will be generated. Otherwise the resulting types will be some what dynamic, types will be boxed with runtime information and dynamic code generated. When no type information is available the compiler generates a lot of dynamic code with a lot of possible exceptions being thrown at runtime.

	add = def (a, b) return a + b
The compiler assumes both parameters are Objects until it comes across the + operator which only accepts two addition_interface objects. The return type and both parameters are set to addition_interface. If the parameters had been declared as Objects the compiler would've inserted code to throw an exception for objects other than addition_interface.

Simply setting the return type to Number would cause both parameters to also be set to Numbers and further reduce the dynamic nature of the function.

	add = def (a, b) -> Number return a + b

Annotating an identifier with the Object type will bypass the above reductions and enable pure dynamic typing for that identifier.

Unboxing
Objects may be unboxed with a type annotation that generates a runtime verification which throws an exception if the object can't be unboxed with that type. Pattern matching is a better way to unbox an object into multiple types without the possibility of exceptions. The best method is to use interfaces that imply specific characteristics about the object.

Previous: Identifiers, Objects and References ----- Up: Contents ----- Next: Garbage Collector