It seems like Mikeal is asking a "why(intent)" question, and getting a lot of "because(causation)" responses.
Yes, the object-as-hash-table is a bit of an antipattern in JS (or, put differently, "things on Object.prototype" is the antipattern), but if we're presenting an Object-looking interface, it should behave like an Object. If we are going to present something that is not an Object interface, then that's another conversation. (I'd be open to process.getEnvKeys() -> Array<String>, process.getEnv(key) -> String, and process.putEnv(key, var, clobber=true) -> Boolean.) Let's just make it work the way people think it ought to: https://github.com/joyent/node/issues/3521 Patches welcome against the current master branch. On Sat, Jun 23, 2012 at 6:17 PM, Marco Rogers <[email protected]> wrote: > Yeah I think there are 2 things happening here. > > - Should process.env and other node host objects try as hard as possible to > behave like real js objects? > > I think the majority says yes here. > > - Should objects used as simple hashes have their prototype nulled out, in > order to avoid some of common pitfalls of this usage? > > This is debatable. My feeling is that it seems to solve some problems, but > people should be aware that it creates some others. Most of the time, you > don't know if you're dealing with an object with no prototype. So you start > trying to do obvious things like call toString on it. Or you pass it into > some other code that tries to call obj.hasOwnProperty. It's easy to say > "dont' do that". But it's much harder to actually make sure no code you > deploy will ever do that. > > Then when you consider what it buys you, it seems less worth it. All it does > is ensure that in the case where you want to use property name that > conflicts with an Object.prototype name, you'll probably be okay. That is > certainly a source of esoteric bugs, but not common ones. And what I've > mostly seen is that it doesn't stop people from being super paranoid and > using Object.prototype.hasOwnProperty or Object.prototype.toString > everywhere. In short, I think we're too far down the road with "real" js > objects being fucked up to say that null prototypes buys us anything truly > worthwhile. > > That said, I don't feel strongly about this either way. > > :Marco > > > On Saturday, June 23, 2012 5:51:29 PM UTC-7, Jorge wrote: >> >> On 24/06/2012, at 02:41, Mikeal Rogers wrote: >> > >> > On Jun 23, 2012, at June 23, 20125:30 PM, Jorge wrote: >> >> On 24/06/2012, at 01:59, Mikeal Rogers wrote >> >>> On Jun 23, 2012, at June 23, 20124:15 PM, Jorge wrote: >> >>>> On 24/06/2012, at 00:43, Mikeal Rogers wrote: >> >>> what is our goal here? >> >>> >> >>> this is all fascinating but rather than call out the warts in the >> >>> language and say people should avoid them we should be trying to make >> >>> node >> >>> not break or behave in an unexpected way for people that don't know the >> >>> language as well as we do. >> >>> >> >>> node is not for javascript experts, it's for people that may be >> >>> learning javascript, and we should avoid unexpected behavior. >> >>> >> >>> do we want to spend our time teaching people the cracks and crevices >> >>> of JavaScript so they can use node or do we want to just make it work the >> >>> way they'll expect? >> >> >> >> The .hasOwnProperty() in Object.prototype has always been a bad idea >> >> because any hasOwnProperty own property or any other hasOwnProperty >> >> property >> >> in the object's [[prototype]] chain will shadow it so in the end -as was >> >> the >> >> case of "with () {}"- you never know for sure *what* are you calling, nor >> >> even if what you're calling is a callable. >> >> >> >> For example, nobody should ever write >> >> httpRequestHeaders.hasOwnProperty('Referer') because it's a bomb waiting >> >> to >> >> explode. That's -I believe- what Bert meant, and I agree. >> >> >> > If your goal is to be right about JavaScript I'll be the first to say >> > "you're right" :) >> > >> > My point is that you can't teach this to everyone in the world writing >> > JavaScript and what we need to do is just make this not an issue in node's >> > core objects. >> >> The point is that, as Bert said: >> >> "People shouldn't rely on prototype methods of objects that are used as >> hash tables. Same story for the http headers object, parsed querystring >> arguments etc." >> >> These objects should *not* have prototypes, *and* not having prototypes >> does *not* make them any less "real js objects" as *you* said. >> -- >> Jorge. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
