Entity Scripts and JS constructors (poll)


There are several different ways to approach constructors in JavaScript – and since Entity Scripts are based on constructors, several different ways to approach Entity Scripts too.

I’m curious to know if there are any strong preferences on this front yet so below is a summarized list of options to consider, followed by a short code example of each (all of which are currently known to work as actual Entity Scripts within Interface).

As a scripter – what type of Entity constructor seems most preferable?

  • Anonymous Function
  • Factory
  • Object Literal
  • JS Class
  • Other

0 voters


“Anonymous Function”

(function() {
  this.preload = function(uuid) {
    print('preload...', uuid);


(function() {
   function MyThing() { }
   MyThing.prototype = {
     preload: function(uuid) { print('preload...', uuid); }
   return new MyThing();

“Object Literal”

(function() {
  return {
    preload: function(uuid) { print('preload...', uuid); }

“JS Class”

function MyThing() { }
MyThing.prototype = {
  preload: function(uuid) { print('preload...', uuid); }


… just for fun here’s an example of “something else” that works



Beyond the Wall of Scripts: Scripting in High Fidelity - Primer for Intermediate Programmers

I suspect this kind of esoteric question is not going to yield meaningful answers unless people understand the ramifications of the different kinds of constructors. And though using JavaScript for scripting is a great choice overall in its flexibility and power, it makes scripting here in HF the single most highest barrier of entry, for most people, to doing anything meaningful other than importing pretty static models.

Some good refs for those who went “huh?”:



Fair enough, but I don’t understand all of the ramifications of the different constructor options yet either… so I guess that makes this a double-blind poll. :wink:

One of the most common pain points though seems to be the “rogue this” scenario – where the system appears to behave almost randomly across signal/event handlers (regarding present value of “this”). In all cases investigated so far, it’s traced back to erosive design choices made near or at the constructor level. Avoiding that is one reason to consider Object Literals as a starting point for all fresh Entity Scripts (requiring no free variables, closures or hard-coded “this” references out of the gate – working directly with Qt’s scoped .connect options wherever available).

Another notable difference I think between approaches relates to direct reuse (ie: importing existing logic). The Anonymous Function works OK in a vacuum – but practically abhors import beyond that. And the Factory approach go far beyond defining a constructor – it also takes ownership over instantiation – which leads to a similar chilling effect on prototypical reuse.

Probably the most reusable (and unit-testable) approach is JS Class – which can double as a Script.include when exported as a global:

MyThing.js (base class)

function MyThingClass() { }
MyThingClass.prototype = {
  preload: function(uuid) { print('preload...', uuid); }
MyThing = MyThingClass;

Which enables importing parts from one Entity Script to use in another:

MyBetterThing.js (extended class)

(function() {
  var instance = new MyThing();
  instance.unload = function(uuid) { print('unload too!', uuid); };
  return instance; // Object.keys(instance) == ['preload', 'unload']

But further direct reuse hits a snag here – since we are forced into the Factory approach (because Script.include only works well from within the constructor body, but that’s too late to leverage the direct JS Class way).


I mabye voted wrong, but it’s hard to see the difference. i know i hate this. but constructors are anyway complex topic. i think name constructors get closer to whst delphi and C# use. but in that example where other confusing things.

i think the js class approche is mabye better and more clear.