An Object is not a Hash

http://www.devthought.com/2012/01/18/an-object-is-not-a-hash/

by philfreo • 14 years ago

66 73 14 years ago

devthought.com

mcot2• 14 years ago

It sounds like this will all be fixed when js gets proper map types in ES6.

just2n3• 14 years ago

When I first saw this post, it didn't include the following snippet:

    Object.create(null);

I disagreed adamantly that a hash with pre-defined names is not a hash. The language already provides a means to get a hash without the pre-defined names, and any clever person can hack around naming collisions regardless. He now notes these things at the end of the article, but then the entire argument doesn't imply that a hash is not a hash. He does a good job pointing out a mistake ALMOST EVERYONE makes, and I applaud that, but the title is horribly misleading, even when given the proper context.

Also, @mcot2, I didn't intend to post as a reply to you, but since I have, to answer your question, collections (Maps, Sets, and WeakMaps) are available in V8 and consequently Node already (via --harmony flags). Because the implementations of these with get/set is not tied to the object's properties, these don't have the same problem.

comex2• 14 years ago

Isn't the whole point of Maps that their get/set methods are completely independent from object properties?

Xcelerate• 14 years ago

It's unfortunate these new map types are so verbose:

object.set(key, value)

object.key = value

dbbolton2• 14 years ago

Contrary to this Stack thread: http://stackoverflow.com/questions/1143498/difference-betwee...

charliesome• 14 years ago

I feel like you missed the point of the article.

dbbolton2• 14 years ago

I feel like you misjudged the tone of my comment.

philfreo• 14 years ago

As a shortcut, in underscore.js you can:

  _.has(object, key)

  _(object).has(key)

http://underscorejs.org/#has

alanh2• 14 years ago

I love that the underscore doc for `has` links to the submitted article.

hakaaak• 14 years ago

Other than lists which can be represented by JSON arrays, hashes do fine jobs at describing most data and most "objects".

This post goes off the rails almost immediately with "Normally this would work fine, but let’s consider that the user could pick any of the keys that are present in any JavaScript object as a name." WTF? The author almost immediately is confusing his/her current situation with the request body and what's in it.

Then we find ourselves quizzically with "We therefore change our code to leverage hasOwnProperty". Umm, I don't think most developers would find themselves "therefore" doing this.

alanh2• 14 years ago

I think you are missing something.

If I understood the article’s example, he’s suggesting the (perfectly plausible) use case of a new blog post named, e.g., `hasOwnProperty`. Then they would want to set a key named `hasOwnProperty` in the `posts` object, but `hasOwnProperty` is already defined (via inheritance, since all objects have it) as a function (well, native code)… so now you have either (a) prevented your blog from allowing a reasonable blog post title, or (b) seriously mucked up your blog by accepting a blog post title that has the side effect of redefining a basic object method.

The author is not confused.

andrewvc3• 14 years ago

The fact is, it's 2012. We all appreciate V8 making the web fast. It's stuff like this, however, that makes me question the sanity of those still promoting node.js

The fact of the matter is that JS is bad at all the things a programming language is supposed to be good at. JS can't even perform integer math. It's also fairly alone in being async by default (and no, comparisons to erlang do not count).

Does JS work? Sure, but believing JS is good is a special kind of delusion. We have decades of language research to work with, and once again we see the pull of the lowest common denominator.

redidas3• 14 years ago

> JS Can't even perform integer math

Can you explain the integer math thing? What exactly can't it do?

snprbob862• 14 years ago

JavaScript's Number type is double floating point:

    $ python
    Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
    [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> x = 1000000000000000001
    >>> x
    1000000000000000001
    >>> x == x + 1
    False

    $ irb
    irb(main):001:0> x = 1000000000000000001
    1000000000000000001
    irb(main):002:0> x == x + 1
    false

    $ clj
    Clojure 1.4.0
    user=> (def x 1000000000000000001)
    #'user/x
    user=> x
    1000000000000000001
    user=> (= (inc x) x)
    false

    $ node
    > x = 1000000000000000001
    1000000000000000000
    > x === x + 1
    true

autarch• 14 years ago

JS has all sorts of problems, but I don't think being async by default is one of them. It's different, yes, but being async by default can be really useful for some tasks.

redidas3• 14 years ago

I've never actually understood why the async thing is so hated. Spend some time in node, and you'll get used to it.

A couple weeks ago I was writing a php script, and it actually felt awkward to query a database and then do something "immediately" after with the result.

It isn't terrible, it's just different. And if you aren't used to it, it'll feel weird at first. This goes away with exposure and experience.

snprbob862• 14 years ago

It certainly can be really useful and thinking in terms of continuation passing style can be kinda fun and enlightening, but it's a pretty awful way to write code normally.

I've used Node.js to good effect. It's a nice piece of software for a whole lot of reasons, but I think Go proves that there is a better way: http://golang.org/doc/effective_go.html#goroutines

brian_cloutier3• 14 years ago

I'd like to know why erlang doesn't count?

There are plenty of reasons to use JS, like "I already know it" if you're a front-end dev, "It's our only option on the client-side and using the same language everywhere is a good idea", or "V8 is heavily optimized so I can not care about performance and usually my code will run fast enough."

Actually that last one is nice. If you don't do anything too stupid, and break up work into lots of little pieces that are called exactly when they're needed, and share as little state as possible, your code runs /much/ faster and is much easier to reason about. node.js gives you those last two properties by default.

Perhaps "JS is inordinately popular for how bad of a language it is", and "Only erlang has the same concurrency model" are related. You can write something that runs as fast in another language or environment, but you won't be able to write it nearly as easily.

riffraff3• 14 years ago

I'd assume erlang doesn't count cause the way you do concurrency in it is the opposite of you do it in node (a bunch of stateless processes communicating over stateful channels vs a single stateful process with callback spaghetti)

mononcqc3• 14 years ago

They don't have the same concurrency model.

JS uses callback-based stuff, cooperative scheduling, and has a single process to drive everything.

Erlang has message-passing to mailboxes, preemptive scheduling, and many fully isolated processes.

jjm2• 14 years ago

Believing anything is good, takes a special kind of delusion. To have and behold one opinion is... well there is history that shows where that goes.

Let us not single out JS specifically as a 'special kind of delusion'. We've all seen 'delusion' in every, single, programming, language, flamewar, on the internet. Seriously.

Everything is a tool, and you choose the right tool for the job. JS adds to the discussion.

If your trying to push JS as a tool to rule them all, that is, thee tool that _must_ do it all well, that is delusional. You'll be prematurely optimizing while(true).

Your not saying that? Then why critique it as if you were?

zinkem2• 14 years ago

It actually isn't completely alone in using an asynchronous paradigm, as you suggest. Delegates in iOS/Cocoa and events in Java work in a similar fashion. Function-queue architectures are not unique to Javascript.

andrewvc3• 14 years ago

My point exactly. Both of those languages are synchronous by default, async is an option. JS is async only pretty much*

* while there are blocking calls in node, they are by far the exception. It is not multi-paradigm like Java

mcantelon• 14 years ago

>Does JS work? Sure, but believing JS is good is a special kind of delusion.

JS, like most languages, is good at certain things, not at others. The edge cases are unfortunate but functionality can be augmented by libraries. Given the momentum behind JavaScript it's fairly likely that these edge cases will disappear in the long term.

ender72• 14 years ago

The people waiting for the programming community to suddenly wake up and realize how wrong they were about Javascript all these years remind me of all the people still waiting for Castro to die.

By the time it happens, it won't actually mean anything because something else, something equally despised and impure will have taken its place.

Perhaps a better question might be why are such languages more popular than their more ideologically pure cousins? What need are they filling that "better" languages cannot? Be careful if your answer is "they're beginner's tools for mediocre programmers" -- the JS community is home to some extremely talented programmers who are all there by choice alone.

blub• 14 years ago

Trying to make one's tools better is always worth it. Typescript is to me the most exciting thing to have happened to JS, better than all the so called libraries that have to be declared inside a function (!!) so that the scope doesn't get completely screwed up.

The JS community is not an argument for JS I feel, because it does not have a track record of providing reliable software. Most libraries are new and a lot of devs are very lax with security or code robustness. If you use a library/tool you're not sure what you're getting - see the semicolon situation or the npm directory deletion.

lmm• 14 years ago

I think JS is in a unique position because of its availability in the browser. Sadly I can't see any good way to get languages I like into the browser.

tincholio• 14 years ago

>why are such languages more popular than their more ideologically pure cousins?

That has a pretty simple answer, it's because it was the only language available in the browser (and no, Java applets never really took off).

Had it been Ruby (unlikely given the timeline) or Python or even Perl instead, the situation would probably be much better today.

zachrose• 14 years ago

JS has two kinds of problems: the kinds of problems like a single number class, and the kinds of problems like implicit global scope. The latter are solved by reading JavaScript: The Good Parts and/or writing CoffeeScript. The former is a result of an idiotically simple core of the language, but also because nobody is clamoring for it. As a trade-off, though, you get JSON!

icebraining• 14 years ago

How is JSON a benefit from a single number class? Python has integers and floats, yet JSON syntax is (almost) valid Python code, including the numbers.

kansface3• 14 years ago

You have overstated how bad JS is in practice. Libraries easily fill in the gaps of the language- Async and Underscore for example. Nodejs is easily the best evented framework for many work cases and that is why it is used.

darkstalker• 14 years ago

Someone should implement Lua in browsers.

jtchang• 14 years ago

Is there some type of injection vulnerability here?

Is it possible to attack a node.js server that creates objects via some API and give it a name that overwrites an internal javascript property? Your content would be the javascript injected code that might get run when the property is used internally?

kansface3• 14 years ago

I suppose its possible, but the most likely case is just an unhandled exception. JSON does not support string literal notation for values which means in practice any function you replace won't be callable. I suppose someone more clever than I or more likely better motivated could combine this attack with another to do some harm.

Having said that, use underscore for the safe references.

drostie2• 14 years ago

That's what the original poster is saying, yes. JS does not support a formal separation between the 'attributes' and 'keys' of a hash, so it's a security risk waiting to happen.

In some cases the JS approach is very nice and useful: in Python you see gobs and gobs of classes used to hold data structures, mostly because people don't seem to like dicts in general. I remember a talk, but not the speaker or title of it, where it was pointed out that your Python class is probably a dict plus a function if it has exactly two methods, one of which is called __init__. Python being what it is, you may also extend Python to do what JS does, but slightly more intelligently:

    class obj(dict):
        def __init__(self, vals={}):
            for key in vals:
                self[key] = vals[key]
        def __setattr__(self, name, value):
            self[name] = value
        def __getattribute__(self, name):
            try:
                return dict.__getattribute__(self, name)
            except AttributeError:
                if name in self:
                    return self[name]
                else:
                    raise AttributeError("'obj' has no key '%s'" % name)

This lets you use dotted setters/getters with Python without accidentally having x['keys'] = 1 override the obj.keys() method (which it inherits from dict). It's a serious problem in real Python code I've read and written; you create 'classes' which are only instantiated once (and are therefore semantically dicts). So the JS model really has some advantages for easy, clear namespacing (and packaging and enumeration) of identifiers, but yes, there is a potential security question if you allow people to set or get arbitrary JS attributes.

inglesp• 14 years ago

I think you're thinking of Jack Diederich's talk "Stop Writing Classes". You can (and should!) watch it online here: http://www.youtube.com/watch?v=o9pEzgHorH0

lucian1900• 14 years ago

I've found in JS what annoys me a lot is that I can't do this

  var x = 'foo'
  {x: 1}

Also, where have you seen that class pattern so much? That seems very odd. I almost always find dicts, sometimes __slots__ classes for CPython performance.

mun2mun• 14 years ago

I think this problem can be easily solved by encapsulating access/creation methods of posts objects in a object say postStore where posts variable is private property and the object have savePost(slug) and getPost(slug) methods where access/creation methods are defined by yourself. If posts object is that much mission critical than it should not be exposed to outer world.

kansface3• 14 years ago

Instead of writing code around the problem, its better to just use a safe reference (ie, use Underscore's has method which will call Object.prototype.hasOwnProperty). This way code stays both simple and safe.

breck3• 14 years ago

> Our program, however, is still susceptible to potential misbehaving. Let’s say our user decides to call his blog post "hasOwnProperty".

This will virtually never happen. If you're worried about it, put an early return (if (name === 'hasOwnProperty') return). End of story.

mtts• 14 years ago

Downvoted because "this will virtually never happen" is, uhm, for want of a better term, incredibly stupid.

Allow what you want to allow and disallow everything else.

breck3• 14 years ago

Sorry, this will happen 00.0001% of the time. Orders of magnitude less than dozens of other more pressing problems.

Groxx• 14 years ago

Unless you run a blogging platform which is used by JS programmers.

Stratoscope2• 14 years ago

Aw gee, you want a real hash in JavaScript, how hard can it be? Here's a quick and dirty one I whipped up in five minutes. It worked the first time with only one bug - I forgot to remove the prefix in the forEach method at first.

  function Hash() {
      this.hash = {};
  }
  
  Hash.prefix = '#hash#prefix#_';
  
  Hash.prototype.get = function( key ) {
      return this.hash[ Hash.prefix + key ];
  };
  
  Hash.prototype.set = function( key, value ) {
      return this.hash[ Hash.prefix + key ] = value;
  };
  
  Hash.prototype.del = function( key ) {
      delete this.hash[ Hash.prefix + key ];
  };
  
  Hash.prototype.forEach = function( callback ) {
      for( var key in this.hash ) {
          if( key.indexOf(Hash.prefix) == 0 ) {
              callback.call( this, this.hash[key], key.slice(Hash.prefix.length) );
          }
      }
  };
  
  // Q&D test
  
  // Let's try to break things by extending Object.prototype!
  Object.prototype.spindizzy = true;
  
  var hash = new Hash;
  console.log( hash.get( 'a' ), hash.get( 'b' ) );
  hash.set( 'a', 'AA' );
  console.log( hash.get( 'a' ), hash.get( 'b' ) );
  hash.set( 'b', 'BB' );
  hash.forEach( function( value, key ) {
      console.log( key, value );
  });
  hash.del( 'a' );
  console.log( hash.get( 'a' ), hash.get( 'b' ) );
  hash.del( 'b' );
  console.log( hash.get( 'a' ), hash.get( 'b' ) );

I'm sure I missed something, but this doesn't seem like rocket science.

Of course, you do lose the syntactic sugar of [] dereferencing so it looks like part of the language, but life is full of tradeoffs! :-)

And I suppose there is still a way to break it, if you extend Object.prototype with something that happens to match Hash.prefix. I guess you could use hasOwnPrototype to prevent this. Ah well, maybe I do have a bug after all, but at least it's a good start.

anonymous2• 14 years ago

Here, let me make this easier for you

  > var hash = []
  undefined
  > hash
  []
  > hash['a']
  undefined
  > hash['a'] = 33
  33
  > hash
  [ a: 33 ]
  > hash[3] = 3
  3
  > hash
  [ , , , 3, a: 33 ]
  > hash[2]
  undefined
  > hash[hash]
  undefined
  > hash[hash] = hash
  [ ,
    ,
    ,
    3,
    a: 33,
    ',,,3': [Circular] ]
  > hash[0] = 'zero'
  'zero'
  > hash['0']
  'zero'

JavaScript already has a perfectly well functioning associative array that can store whatever keys you like with the only gotcha being that strings containing only numbers act like numbers, when used as keys.

lnanek2• 14 years ago

I'm not a JS programmer, but isn't that just an array? Which extends Object. Which has all the failings that the article mentions? What happens when you try to insert hasOwnProperty? Do you lose access to the superclass hasOwnProperty like the {} object literal's drawback the article mentions? I suspect you do.

Stratoscope2• 14 years ago

That has a couple of problems. Try this:

  > var hash = [];
  undefined
  > hash
  []
  > hash['length']
  0
  > // Hey! That should have been undefined, not 0!
  > hash['length'] = 'test'
  RangeError: Invalid array length
  > // And I can't set it either!

Also, the part where you're doing hash[hash] doesn't do at all what you think. When you write this code:

  hash[hash] = whatever;

What you're really doing is:

  hash[ hash.toString() ] = whatever;

And with hash being an array, hash.toString() is highly browser dependent. In Chrome, if you don't have any numeric array keys, then hash.toString() is "" regardless of your non-numeric keys (at least in the version I'm testing). So you may well be really doing this in Chrome:

  hash[""] = whatever;  // Oops

If you do want to use a native JavaScript type as a hash, the one to use is Object, not Array. Simply change the first line of your test to:

  var hash = {};

and go from there.

This still doesn't solve the name collisions, but is plenty useful anyway.

If you do want a more fool-proof hash that lets you use any string as a key without fear, I'm pretty sure you need to write some code like the Hash class I posted. You still couldn't do the hash[hash] - or hash.get(hash) - because of the dependence on .toString(), but any string key would work. You could even get fancy and give the Hash class some kind of useful .toString() method so you could use hash[hash] - having your own code here opens up those kinds of possibilities.

mercurial• 14 years ago

It's a pretty good illustration of why associative arrays in Javascript are a design failure, by conflating different notions in the same implementations:

- objects are not hashes

- hashes are not arrays

It sounds like somebody reading the classic quote by Saint Exupéry, "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.", and concluding: "Well, if I mash all the elements to a paste, there won't be anything to take away."

cousin_it• 14 years ago

    if (!posts.hasOwnProperty(req.body.slug)) {
      posts[req.body.slug] = new Post(req.body);
      res.send(200);
    }

Maybe I'm missing something, but doesn't that code also happily assign to properties like "constructor", not just "hasOwnProperty"?

An Object is not a Hash

Related Stories