@Christoph-Hart: I see, your concerns about the GC are valid. Memory leaks in these type of application are horrible. Thanks for pointing out this behaviour of the Javascript Engine garbage collector. I will definitely take these into account.
I have been refining and simplifying the method above:
/* The helper manager that helps us instantiate new objects */
function ObjectManager(){
return {
construct: function(prototype, parameters){
var instance = PrototypeFactory(prototype);
if(typeof(instance.construct) === "function"){
instance.construct(parameters);
}
return instance;
}
}
}
/* Note: you need to add all your class definitions to this factory */
function PrototypeFactory(name){
switch(name){
case "Cat":
return Cat();
}
}
/* Now we can just define classes in a modern Javascript fashion, like this Cat class with some properties and methods */
function Cat(){
return {
name: "Garfield",
construct: function(parameters){
this.age = parameters.age;
},
printInformation: function(){
Console.print("Age: " + this.age);
Console.print("Name: " + this.name);
}
}
}
/* Now we can instantiate objects of that class */
var cat = ObjectManager().construct("Cat", {age: 2});
cat.printInformation();
/*
Outputs:
Age: 2
Name: Garfield
*/
var olderCat = ObjectManager().construct("Cat", {age: 4});
olderCat.printInformation();
/*
Outputs:
Age: 4
Name: Garfield
*/
Again, i'm still experimenting and planning my code design strategy. Is there a way that I can monitor the Javascript engine's object count thru the API? Something like (pseudocode):
const var objectCountTimer = Engine.createTimerObject();
objectCountTimer.callback = function()
{
Console.print("Object count: " + Engine.getObjectCount());
};
objectCountTimer.startTimer(10000);
Besides that fact that this would allow me to test my design strategy for memory leaks, I think it would be a really nice addition to the framework because it allows monitoring of object instance regression (at least during debugging) and analyzing the behaviour of the Javascript Engine GC.
It's not that i'm planning to do very advanced OO Javascript stuff, so no inheritance etc. Just some basic prototyping and instantiation.. should that work (without memory leaks) than that would be my prefered strategy in contrast to using the C++ API. Just because i'm more comfortable with Javascript then C++ now-a-days.
So the GUI design I have in mind for this particular plugin i'm building is a very dynamic in nature, i'm trying to dynamically modify the module backend (Effects & Modulators) based on the users input. So for this to work, the Javascript Engine must be able to free memory of (my custom Javascript UI) objects that are unreferenced and go out of scope, otherwise it will leak like hell (like you mentioned) and render my method (mentioned above) totally unusable. Today I'll try to attach some custom C++ code using the C++ API, try and see how that works out.
Ps. It's good to know that a script panel can hold a custom data object, that would allow me to go for a more C stylish approach inside Javascript instead of the my custom OOP approach above. Like putting all the logic in a namespace and let the script panels cary their own data. Will give this approach a shot too, but I slowly getting the feeling that I need to go down the C++ road for my idea to work properly (and keep my code clean/maintainable).
Update: I found out that the object oriented Javascript method failed when trying to access class properties from within a callback function:
function DisplayComponent(){
return {
backgroundColor: Colours.green,
construct: function(parameters){
this.setPaintRoutine();
},
setPaintRoutine: function(){
var classthis = this;
Display.setPaintRoutine(function(g)
{
g.fillAll(classthis.backgroundColor);
});
}
}
}
It just can't access that backgroundColor property from within that scope. I could not find any documentation or examples on how to implement custom C++ code so i'm going to see if i can do something with the data object holder inside Script panel and build my design around that.
