Next: Constructor Implementation, Previous: Class Declaration Syntax, Up: Class Module Design [Contents]
B.1.2 Class Storage
One of the more powerful features of ease.js is how classes (and other objects, such as Interfaces) are stored. Rather than adopting its own model, the decision was instead to blend into how JavaScript already structures its data. Everything in JavaScript can be assigned to a variable, including functions. Classes are no different.
One decision was whether or not to store classes internally by name, then permit accessing it globally (wherever ease.js is available). This is how most Object-Oriented languages work. If the file in which the class is defined is available, the class can generally be referenced by name. This may seem natural to developers coming from other Object-Oriented languages. The decision was to not adopt this model.
By storing classes only in variables, we have fine control over the
scope and permit the developer to adopt their own mechanism for organizing
their classes. For example, if the developer wishes to use namespacing, then
he/she is free to assign the class to a namespace (e.g.
‘org.foo.my.ns.Foo = Class( {} )’). More importantly, we can take
advantage of the CommonJS format that ease.js was initially built for by
assigning the class to module.exports. This permits ‘require(
'filename' )’ to return the class.
This method also permits defining anonymous classes (while not necessarily recommended, they have their uses just as anonymous functions do), mimic the concept of Java’s inner classes and create temporary classes (see Temporary Classes). Indeed, we can do whatever scoping that JavaScript permits.
B.1.2.1 Memory Management
Memory management is perhaps one of the most important considerations. Initially, ease.js encapsulated class metadata and visibility structures (see Hacking Around the Issue of Encapsulation). However, it quickly became apparent that this method of storing data, although excellent for protecting it from being manipulated, caused what appeared to be memory leaks in long-running software. These were in fact not memory leaks, but ease.js keeping references to class data with no idea when to free them.
To solve this issue, all class data is stored within the class itself (that is, the constructor in JavaScript terms). They are stored in obscure variables that are non-enumerable and subject to change in future releases. This ensures that developers cannot rely on using them for reflection purposes or for manipulating class data during runtime. This is important, since looking at such members can give access to protected and private instance data. In the future, the names may be randomly chosen at runtime to further mitigate exploits. Until that time, developers should be aware of potential security issues.
If the globally accessible model would have been adopted (storing classes internally by class name rather than in variables), classes would not have been freed from memory when they went out of scope. This raises the memory footprint unnecessarily, especially for temporary classes. It would make sense that, after a temporary class is done being used, that the class be freed from memory.
Given this fact alone, the author firmly believes that the model that was chosen was the best choice.
Next: Constructor Implementation, Previous: Class Declaration Syntax, Up: Class Module Design [Contents]
