Skip to content

adding props to objects - alternatives #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
davidmarkclements opened this issue Aug 22, 2014 · 0 comments
Open

adding props to objects - alternatives #2

davidmarkclements opened this issue Aug 22, 2014 · 0 comments

Comments

@davidmarkclements
Copy link

Hey man love what you're doing here, just a couple of ideas for you

Instead of adding multiple properties namespaces vs* and vs_* how about you
just add a vs object,

so, for instance in the instrumentObject function you would do

    obj.vs = {
       //private fields
       _name: args.name,
       _counters: {},
       _context: null,

       //public methods
       name: vsName,
       counters: vsCounters,
       counterBump: vsCounterBump,
       warn: vsWarn
    };

This would be more idiomatic JS in terms of convention (e.g. privates) and
of course reduces the pollution vector down to one property.

Obviously this will be API breaking but hopefully it's early enough for you to do that.

If for whatever reason you need to keep the API and maybe relegate namespacing
everything under vs.* till a later version, you could mitigate some of the problems
of property pollution by hijacking the prototype chain - see my fork here

https://github.com/davidmarkclements/node-vstream/blob/master/lib/vstream.js#L75-L90

for how to do that.

This way, if there are any (..fairly unlikely but you can never be sure) clashes between your
property and a users property then the users property win instead of vstreams which I believe
is inline with your design philosophy on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant