HFL support for javascript-style objects
- HFL supports a version of javascript-style objects that mirrors many of the features of true javascript, including prototypes, constructors, methods, properties and inheritance.
- The HFL object-orientation behavior is the same as in javascript, which is based upon linked object prototypes instead of classes.
- The type of object-oriented programming (OOP) used by javascript has many advantages over class-based OOP, allowing a great deal of flexibility in object behavior. It is also far less structured than class-based OOP, which to some may seem a disadvantage.
- HFL supports several of the more commonly-used object types and methods, such as for strings, arrays, and Math functions, but for performance reasons this subset is kept to a minimum in the core compiler. All other object types and methods can be added by loading libraries.
- HFL does allow its object model to be extended as needed, so any missing methods or objects can be easily added. (See the section on 'Extending Object Model'.)
Objects are expensive
- While HFL does support js-style objects, OOP in general has a large overhead. This is especially true the way that it is implemented in javascript, as object data is quite large, and all properties and methods must be searched for by traversing the prototype chain at run-time. This can cause a noticeable performance loss over direct function calls.
- As HFL can run under a web server, performance is very important. So HFL works with objects somewhat differently than does javascript. It avoids creating full objects for simple data types like strings and arrays unless and until they are actually used as objects. This keeps memory usage much lower, and direct access to data is far more efficient than object-oriented access. When a simple data type is accessed using object methods, the data is converted ("coerced") into an object.
- HFL provides standard-format function versions for almost all of the OOP methods of standard data types such as String and Array. The function versions will have much better performance when applied to simple data types such as strings and arrays because the data types do not have to first to be converted to objects in order to invoke the methods.
- Objects can be a good choice when you need a record structure, as the data is all in one place. But for simple data types, it is recommended that you use direct function calls instead of applying object methods.
- As an example, below we show the same operations done as both direct-access and as OOP methods. The OOP method versions are more inefficient because they require that the strings be converted to intermediate objects in order to be able to call the methods on them. Both approaches produce the same result.
-
var s1 = "Now is the time for all good men";
// Create the substring 'Now' two different ways
var s2 = substr(s1, 0, 3); // Efficient
var s3 = s1.substr(0, 3); // Inefficient: Creates intermediate object
// Print the value of the string variables two ways
print("s2 is '"+s2+"'"); // Efficient
print("s3 is '"+s3.valueOf()+"'"); // Inefficient: Creates intermediate object