3 ms·

How does node get this 'very right'? Why is the 'code encapsulation' ruined now that he's monkey patched String? What should he have done instead? I personally

by tinco 13y ago

How does node get this 'very right'? Why is the 'code encapsulation' ruined now that he's monkey patched String? What should he have done instead? I personally love monkey patching system libraries, it makes your code look pretty. I guess it's one of the guilty pleasures of a Ruby developer. On the subject of awesome languages like Ruby, did you know that C# actually has a way of safely monkey patching system libraries? It's called 'extension methods' and it's actually the bees knees. Too bad C# has a proprietary side that makes it less desirable for business critical software, leaving us with Ruby.

rgbrgb 13y ago
It's the kind of thing that could possibly be OK in nodejs but is not OK in the browser. My biggest problem with it (and how it goes down in Rails for that matter) is that you can inadvertently clobber variables in namespaces you don't own. Changing the prototype of String there will change it in the context of every 3rd party library that's also running. It just doesn't scale with the codebase.
- secoif 13y ago
  > possibly be OK in nodejs but is not OK in the browser. I think you've got that around the wrong way. It's more of a problem in node/browserify because you're typically working with very many more 3rd party libraries.
  - rgbrgb 13y ago
    Yeah, that's fair. The bottom line is please never do it or teach noobs to do it without telling them why it's wrong.
secoif 13y ago
He/she should have just used a regular method. Yeah it makes the code pretty, but it pollutes every library in your environment. You don't do this for the exact same reason you don't use globals. String.prototype is a global. Don't mess with it. By not messing with globals, node allows you to safely load multiple versions of the same module and not worry about strange runtime environment changes. It probably doesn't matter in this trivial case, but node's primary win is how easy and safe it is to write and share modular code so yeah, prototype pollution is a destructive anti-pattern.

by tinco 13y ago

rgbrgb 13y ago

It's the kind of thing that could possibly be OK in nodejs but is not OK in the browser. My biggest problem with it (and how it goes down in Rails for that matter) is that you can inadvertently clobber variables in namespaces you don't own. Changing the prototype of String there will change it in the context of every 3rd party library that's also running. It just doesn't scale with the codebase.

secoif 13y ago
> possibly be OK in nodejs but is not OK in the browser. I think you've got that around the wrong way. It's more of a problem in node/browserify because you're typically working with very many more 3rd party libraries.
- rgbrgb 13y ago
  Yeah, that's fair. The bottom line is please never do it or teach noobs to do it without telling them why it's wrong.

secoif 13y ago

He/she should have just used a regular method. Yeah it makes the code pretty, but it pollutes every library in your environment. You don't do this for the exact same reason you don't use globals. String.prototype is a global. Don't mess with it. By not messing with globals, node allows you to safely load multiple versions of the same module and not worry about strange runtime environment changes. It probably doesn't matter in this trivial case, but node's primary win is how easy and safe it is to write and share modular code so yeah, prototype pollution is a destructive anti-pattern.