I want to create a DSL-like builder for my javascript object, but i'm not sure that DSL-Builder object is removed by garbage collector (created object). Here's the code:
function Section() {...}
Section.DSL = function() {
var section = new Section();
return {
title: function(s) { section.title = s; }, /* Just for example */
content: function(s) { section.content = s; }, /* Logic has been removed */
section: section
}
}
function section(builderFn) {
var dsl = new Section.DSL();
fn.call(dsl, dsl);
return dsl.section;
}
/* Somewhere in the code */
var mySection = section(function(s) {
s.title('Hello, my section');
s.content('We can put it in later');
});
/* I want my DSL object created internally by section method
to be removed by garbage collector */
I'm going to use DSL only to initialize a new instance of Section and fill its values using convenient methods. I want my DSL object to be disposed and i'm not sure that it is going to be according to my further usage of one of its members.
Maybe i should create a "dispose" method, which will set dsl.section to null or delete it using "delete dsl.section"? After that my section will be disconnected from DSL and it will be successfully removed by garbage collector and i continue to use it via new reference "mySection".
There is another idea:
There is a possibility to use DSL as singleton. It that case i have to create a new Section object inside a "section" method and just assign it to DSL object (which will be a singleton) before calling a builder function. Is it a good solution? Example follows:
Section.DSL = {
construct: function(section) {
this.section = section;
return this;
}
/* Builder methods */
}
function section(builderFn) {
var section = new Section();
/* Imagine that DSL is just an object with a few functions
and construct just set its section variable and returns this
*/
var dsl = Section.DSL(section); **/
fn.call(dsl, dsl);
return section;
}
The GC is only concerned about object-reachability. In any case, consider these examples:
function f (s) {
// The variable "s" is a reachability root for the given scope;
// any object that it names is guaranteed to be reachable
// as long as the closure(s) below are reachable.
return {
getIt: function () { return s }
setIt: function (_s) { s = _s }
}
}
Example Case 1.
g = f({my: "Object"})
// Closures are no longer strongly reachable, and thus the object
// can be reclaimed.
// (Also note there are no other strong references to the object!)
g = null
// Told yah, so, oops exception!
g.getIt()
Example Case 2.
g = f({my: "Object"})
// The variable "s" bound by the closures has been re-assigned and
// thus no longer strongly references the original object;
// the original object is thus eligible for reclamation.
// (Note no other strong references!)
g.setIt(null)
// But of course we just have null now .. oops!
g.getIt().my
Example Case 3.
o = {my: "Object"}
g = f(o)
g.setIt(null)
// ..but the object is NOT eligible for reclamation because it is
// strongly reachable through "o" (which is a reachability root
// in this scope).
alert(o)
Now, the only real cases of interest (that I eluded to in my comments) is:
function f2(s) {
var hash_of_s = hash(s)
// The variable "s" is not accessed from any closure
return {
getHash: function () { return hash_of_s }
}
}
g = f2(/* some LARGE object currently only reachable here */)
// Is the object referenced by "s" reclaimable here?
alert(g.getHash())
In this case, assuming the closure is strongly reachable, does "s" maintain reachability of the initial object?
An implementation could technically decide that "s" does not maintain reachability - but I do know how Node.js handles it.