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
