Javascript private variables and inheritance

In Uncategorized on April 8, 2018 by sdobney

[Internal open discussion about programming, that we’re leaving open in case anyone disagrees or has suggestions]

Unlike other programming languages, in Javascript makes the use of private variables in object definitions difficult and where an object is to be extended there is no obvious method of using private variables at all. This leaves all parameters open, which runs the risk of mis-programming or accessing status variables that should not be touched externally.

The standard method for creation private variables is simple:

function cards() {
    let current=0;
    let step=1;
    let pack=[...51];
    let size = pack.length
    function dealCard() {
        current = current + step % size;
        return (current)

In this example, variables current, pack, step, size and the function dealCard() are private. We can expose the function with this.dealCard=dealCard; or return( { dealCard });

Access to the private variables is not possible from outside, which means that the object can maintain the integrity of the values and the data;

For instance, an alternative would be to use this.current instead of the private variable current. Thus exposing the current index externally.

However, this then leaves the risk that code outside the object could try something like


Thus creating a value out of scope which will throw an error within the object when dealCard() is called, but not as a result of code in the object. Worse, we can ask for any undefined property – eg pack.currentCard and we may not know it’s undefined.

There are methods to define independent getters and setters for each variable, but we can get also single functions that affect more than one of our status variables. For instance if we had function removeCard(id), we would like the array to be reduced, but also adjust the size.

Our preferred programming style is thus to have an object with internal variables that are loaded with external data with suitable error checking, and that are exposed according to settings and permissions. We often use the following style

  • initiate(id) -> load(data) -> { internal } -> process(action) -> request(data)

In this style, the object controls what can be returned, and internal status and data values are not exposed to other objects directly. The object handles requests for internal data. This means code to manipulate the object’s data stays in the object, and the object can do things like make sure a number is between two values, that a data item is not blank, and that the viewer/requester has permission to request the data.

For instance, in our cards example, we would have a function to shuffle() the pack, and others to add() and remove() cards, but only via methods from the object itself. We can’t cheat and manipulate the pack externally as we would be able to if all properties are exposed.

As we’ve seen, private variables are not a problem when we initialise them in the constructor. And they can be manipulated with functions created in the same constructor because they sit in the same variable scope.

What we can’t do is add functions post closure. We can’t, for instance, use

cards.prototype.lastCard() { return(pack[counter-1]); }

because our prototype function is now out of scope with the private variables.

This then has the knock-on problem that in Javascript we cannot use object inheritance with private variables, because those private variables do not get initialised at the top level of the object.

To explain: We might like to use

TripleCards=new Cards; 
TripleCards.tripleStep=function() { step=3; }

In other words extending the base class. However, because step is scoped to the initial Cards object, we do not see it when extending the object. We get a scoping problem when extending objects. The only way possible is to use this.step and thus expose the internal variable.

We can obviously program ‘by convention’ eg signalling a private value or private function with an underscore as is common: _myvar but this still leaves the risk of external code manipulating the object externally from the object itself and thus breaking status.

Thinking to be developed….





Rethinking Questionnaires – fly menus

In Uncategorized on November 2, 2016 by sdobney

The second of our series on Rethinking Questionnaires is now at LinkedIn. As mentioned, our focus is on re-imagining what and how a questionnaire can be. Many of the research tools we use today are online replicas of surveys that could have been carried out 70-80 years ago; in reality not that much has changed. With the availability of computer-based interviewing via web-surveys the lack of innovation is quite surprising.

Our second demonstration of fly-menus which are used for drill-down and non-linear approaches to questionnaires can be found here:

Fly-menus are a structural approach to a problem that the linearity of questions in a questionnaire (from A to Z) is determined by the researcher and not down to the respondent saying what they are interested in, or what they would give their time to answer. A fly-menu approach says to the respondent, here are the topics, you choose which topics you want to tell us about, and in what order. This is why we also refer to this as a non-linear questionnaire structure.

It actually breaks quite a big taboo. In surveys we are fully aware that there are order-effects. That is the order in which you ask questions can affect the responses that we get. For some areas like prompting where we prefer to find out what someone knows or thinks spontaneously or semi-spontaneously before introducing the ideas, do still rely on question order. But for approaches such as customer satisfaction research, it should be the respondent/customer who determines the order of questions and prioritises what they want to order.

More specifically, we know that more attention is applied to earlier items when answering questions like scale questions. Though this illustrates a weakness of scale-based approaches in that simple re-ordering changes the answers, it also suggests that we should work with the respondent on the areas that they want to give attention to because then we will have better answers.

The original LinkedIn article on fly-menus is here.


Rethinking questionnaires – hot-cold scales

In Uncategorized on November 2, 2016 by sdobney

Over at LinkedIn we are have included some posts and demonstrations on Rethinking Questionnaires with new ideas for question design, questionnaire structure, blending surveys with websites and social media. A demonstration can be found here:

The first looks at hot-cold scales. These are use buttons and images to allow respondents to say what they like or don’t like, but crucially, we don’t force a response. Because of our work looking at choices and choice making, we feel that forcing tends to mix weakly-held with strongly-held views. Choices on the other hand enable a respondent to review a large group of items rapidly and naturally, much as they might do with an on-line or actual paper catalogue, only focusing on the items that are of interest.

The original LinkedIn article is here.


MR and Customer centricity

In Uncategorized on May 5, 2016 by sdobney

Edward Appleton in his entertaining and provocative market research blog asks “why, given that Market Research and Marketing been preaching customer-focus for decades, so often one experiences lousy customer experience?”

Read More »


How big is Big Data?

In Uncategorized on November 24, 2014 by sdobney

In a seminar on Big Data in Barcelona this week, a consultant from Ernst and Young (EY) Consulting suprised me by suggesting that 43% of Big Data projects involved less than 10,000 records running up to 71% of Big Data projects that used less than 1 million records. This was a surprise as my assumption of Big Data was that it was really N-million record type projects.

Read More »


Orthogonal designs in conjoint analysis

In Uncategorized on May 12, 2014 by sdobney

Conjoint analysis (or discrete choice estimation/stated preference research) broadly has four main components. The attributes and levels that make up the product or service that we want to test, a statistical design to choose combinations of attributes and levels in order to convert them into product profiles that reflect the decision space, a choice method – usually direct choice but it could include an estimation of volume (eg number of prescriptions for medical subjects), a ranking, a multiple selection eg of items into a consideration set, or a rating in a more old fashioned conjoint, a method of analysis – normally Hierarchical Bayes or MLE and a modelling. Of these, the element that is most troublesome is the statistical design. With large numbers of attributes and levels, it is impossible to test all combinations, so we have to choose a subset (a fractional factorial design). Read More »


Comparing Open Office, Libre Office and Microsoft Powerpoint for market research charts

In Uncategorized on March 6, 2014 by sdobney Tagged: , , ,

Charting is one of the main reporting methods for quantitative research, and most companies use Powerpoint. With Open Office and Libre Office now reaching version 4.0+ we’re discovering that Open Office is now getting good enough for productive chart production for market research. Read More »