Response to _Opportunity

id.js

// I'm going to leave my debugging code in so you can see how I prove to myself that I've resolved issues
/* I added the NAMESPACE declaration to troubleshoot. 
* I understand this was only part of a larger 
* codeblock that may or may not have declared NAMESPACE
*/
var NAMESPACE;
if (!NAMESPACE || typeof NAMESPACE == 'undefined') {
    NAMESPACE = {
        _all_ids: new Object()
    };
    var id = function (id) {
        var persona = {};
        // shorthand reference
        var _all_ids = NAMESPACE._all_ids;
        // local var declaration
        var _id = id;
        /* because the id gets deleted from _all_ids on close() invocation, I imagine it should be added also.
        * but I have no clue to what end numbers are added or deleted from this array.
        */
        // added terminating semi-colon to end of function
        var getId = function () {
            // use of local var
            return _id;
        };
        // assignment of function to returned object
        persona.getId = getId;
        // add the current _id to _all_ids
        _all_ids[_id] = persona;
        // local var declaration
        var _closed = false;
        // added terminating semi-colon to end of function
        var close = function () {
            delete _all_ids[getId()];
            // the line below references a prototypal property that doesn't seem to be in existence 
            // this._closed = true;
            // the output below should prove that this._closed is an improper reference
            console.log('according to the original code, this should be false, not undefined.', this._closed);
            // instead, I'll reference the local property created above
            _closed = true;
        };
        
        persona.close = close;
        
        return persona;
    }

    NAMESPACE['id'] = id;
}

I would have to say no since I've ruled out the possiblity of prototypal shenanigans. It would lead me to believe that it should be part of the NAMESPACE object. This possibility may be further confirmed by the name _all_ids since its formatted in an internal-ish style.

Excellent, so how can we fix it? Is it as simple as NAMESPACE._all_ids = {}, or should we do something else? What are the benefits/drawbacks to such an approach (vs. another)?

Like a list of users for messaging or somesuch activity, which would explain close perhaps.

Great examples.

For keeping track of ids that are yet to be closed. So an instance generated by id can be found and then deleted after a message/result is delivered/returned.

Let's write some tests that demonstrates how we expect close to work, then get those tests to pass (which probably implies fixing where _all_ids lives and how it's used).

We're getting there! 😁

I would recommend migrating this to a GitHub repository, since it provides better tools for this kind of thing. (At the very least, we'll know that @-style mentions notify the mentioned party).

@posita,
I'll begin immediately.

@posita,
see the repository

@posita,
Is it as simple as NAMESPACE._all_ids = {}, or should we do something else? What are the benefits/drawbacks to such an approach (vs. another)?
Pros

1. Simple is awesome, unless it's overly simplistic. What's more, it seems to work judging by the tests I've included in the repository.

Cons

1. There's no protection from _all_ids getting overwritten or deleted accidentally.
2. There would be no event hooks, etc.
3. There would be no facility for features such as undo.

My recommendation: There is precedent in the code to declare a local and return the local from a function, a la var getId = function() {}; persona.getId = getId;
This will take care of Cons 1 which is critical while Cons 2,3 are pre-optimizey and I've seen no indication such features are necessary so far.