Re: [nodejs] process.env.hasOwnProperty

[Ben Noordhuis]

On Fri, Jun 22, 2012 at 6:04 PM, Martin Thomson
<martin....@gmail.com> wrote:
> process.env instanceof Object === true
> typeof process.env.hasOwnProperty === undefined
>
> Bug?

`process.env` is not a real JS object. it's a stub for a chunk of C++
code. But by all means file an issue if you feel strongly about this,
we can probably fix it.

[Bert Belder]

On Friday, June 22, 2012 6:27:49 PM UTC+2, Ben Noordhuis wrote:

`process.env` is not a real JS object. it's a stub for a chunk of C++
code. But by all means file an issue if you feel strongly about this,
we can probably fix it.

 
I don't agree. 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.

- Bert

[Ben Noordhuis]

Apparently Bert feels strongly about this. :-)

[Mark Hahn]

>  Same story for the http headers object, parsed query string arguments etc. 

So my putting the parsed query string and everything else related to a request on the request object node gives me is right out then?  I guess I'm going to hell.

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Isaac Schlueter]

I somewhat agree with Bert here.

On the other hand, we just outright block querystrings from having
keys named hasOwnProperty, __defineGetter__, etc., and I believe we
may do the same for http headers. We probably ought to make a
decision and have them all work the same. I'd be tempted to maybe add
some kind of "not instanceof Object object" goober and use for these
cases.

On Fri, Jun 22, 2012 at 4:58 PM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:

[Mikeal Rogers]

process.env should be a real js object, or at least act like one.

if we have to i'd say we make process.env a getter and build a real js object from the C++ stub that is currently there.

people should not be expected to know or distinguish between normal js objects and crazy things from C++.

-Mikeal

[Koichi Kobayashi]

Hi,

$ node
> noProto = Object.create(null);
{}
> noProto instanceof Object
false

`process.env instanceof Object` should be `false`
if it has no prototype.

[Jorge]

Object.create(null) objects are real JS objects and act like real JS objects.

[Marco Rogers]

Yep. And I always steer people away from instanceof. It's too unpredictable and often unnecessary.

I'm in agreement with Mikeal. As often as possible you should try to make node host objects behave like js objects.

:Marco

On Saturday, June 23, 2012 12:20:50 AM UTC-7, Jorge wrote:

Object.create(null) objects are real JS objects and act like real JS objects.

On Jun 23, 2012, at 2:04 AM, Mikeal Rogers wrote:

> process.env should be a real js object, or at least act like one.
>
> if we have to i'd say we make process.env a getter and build a real js object from the C++ stub that is currently there.
>
> people should not be expected to know or distinguish between normal js objects and crazy things from C++.
>
> -Mikeal
>
> On Jun 22, 2012, at June 22, 20124:58 PM, Ben Noordhuis wrote:
>
>> On Fri, Jun 22, 2012 at 7:22 PM, Bert Belder <bertb...@gmail.com> wrote:
>>>
>>>
>>> On Friday, June 22, 2012 6:27:49 PM UTC+2, Ben Noordhuis wrote:
>>>>
>>>> `process.env` is not a real JS object. it's a stub for a chunk of C++
>>>> code. But by all means file an issue if you feel strongly about this,
>>>> we can probably fix it.
>>>
>>>
>>> I don't agree. 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.
>>
>> Apparently Bert feels strongly about this. :-)
>>
>> --
>> 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 nod...@googlegroups.com
>> To unsubscribe from this group, send email to

>> nodejs+unsubscribe@googlegroups.com

>> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to

> nodejs+unsubscribe@googlegroups.com

> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

On Saturday, June 23, 2012 12:20:50 AM UTC-7, Jorge wrote:

Object.create(null) objects are real JS objects and act like real JS objects.

On Jun 23, 2012, at 2:04 AM, Mikeal Rogers wrote:

> process.env should be a real js object, or at least act like one.
>
> if we have to i'd say we make process.env a getter and build a real js object from the C++ stub that is currently there.
>
> people should not be expected to know or distinguish between normal js objects and crazy things from C++.
>
> -Mikeal
>
> On Jun 22, 2012, at June 22, 20124:58 PM, Ben Noordhuis wrote:
>
>> On Fri, Jun 22, 2012 at 7:22 PM, Bert Belder <bertb...@gmail.com> wrote:
>>>
>>>
>>> On Friday, June 22, 2012 6:27:49 PM UTC+2, Ben Noordhuis wrote:
>>>>
>>>> `process.env` is not a real JS object. it's a stub for a chunk of C++
>>>> code. But by all means file an issue if you feel strongly about this,
>>>> we can probably fix it.
>>>
>>>
>>> I don't agree. 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.
>>
>> Apparently Bert feels strongly about this. :-)
>>
>> --
>> 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 nod...@googlegroups.com
>> To unsubscribe from this group, send email to

>> nodejs+unsubscribe@googlegroups.com

>> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to

> nodejs+unsubscribe@googlegroups.com

[Mikeal Rogers]

yes, the language has warts, what is your point?

[Jorge]

On 24/06/2012, at 00:43, Mikeal Rogers wrote:
>
> On Jun 23, 2012, at June 23, 201212:20 AM, Jorge wrote:
>>
>> On Jun 23, 2012, at 2:04 AM, Mikeal Rogers wrote:
>>
>>> process.env should be a real js object, or at least act like one.
>>>
>>> if we have to i'd say we make process.env a getter and build a real js object from the C++ stub that is currently there.
>>>
>>> people should not be expected to know or distinguish between normal js objects and crazy things from C++.
>>>
>> Object.create(null) objects are real JS objects and act like real JS objects.
>

> yes, the language has warts, what is your point?

That I agree 100% with Bert:

On Fri, Jun 22, 2012 at 7:22 PM, Bert Belder <bertb...@gmail.com> wrote:
>
> 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.

--
Jorge.

[Rick Waldron]

On Sat, Jun 23, 2012 at 6:39 PM, Marco Rogers <marco....@gmail.com> wrote:

Yep. And I always steer people away from instanceof. It's too unpredictable and often unnecessary.

I'm in agreement with Mikeal. As often as possible you should try to make node host objects behave like js objects.

+9001

This is literally why the DOM is such a nightmare. There are many "special" objects that have some degree of special treatment or limitation.

Rick

 

nodejs+un...@googlegroups.com

[Mikeal Rogers]

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?

-Mikeal

[Jorge]

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:
>>> On Jun 23, 2012, at June 23, 201212:20 AM, Jorge wrote:
>>>>>
>>>> Object.create(null) objects are real JS objects and act like real JS objects.
>>>
>>> yes, the language has warts, what is your point?
>>
>> That I agree 100% with Bert:
>>
>> On Fri, Jun 22, 2012 at 7:22 PM, Bert Belder <bertb...@gmail.com> wrote:
>>>
>>> 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.
>>

> 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.
--
Jorge

[Mikeal Rogers]

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.

[Jorge]

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.

[Marco Rogers]

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

[Mikeal Rogers]

You and Bert are technically correct but what you're correct about doesn't matter.

Should node cause an exception on accessing this prototype which many people expect to be there?

The answer is obviously "no" only because it's much easier to make it not a problem that anyone ever sees than it is to explain this to everyone who gets this error.

If you reply with another email explaining to me how JavaScript works I'm seriously going to flip out.

-Mikeal

[Isaac Schlueter]

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.

[Ben Noordhuis]

On Sun, Jun 24, 2012 at 3:52 AM, Isaac Schlueter <i...@izs.me> wrote:
> 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.)

God, that's horrible. My eyes, they're bleeding!

[mscdex]

On Jun 23, 10:09 pm, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> God, that's horrible. My eyes, they're bleeding!

Agreed

[Jorge]

LOL.

@izs: please forget that!

Most people already know how to do it: ({}).hasOwnProperty.call(process.env, "property");

To those who don't: this is yet another lovely JS WTF!
--
Jorge.

[Jorge]

On 24/06/2012, at 02:41, Mikeal Rogers wrote:

> 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.

So now we agree: don't teach anybody if you don't want to, nor put methods in the prototype when you shouldn't :-P
--
Jorge.

[Bert Belder]

On Sunday, June 24, 2012 3:17:23 AM UTC+2, Mikeal Rogers wrote:

You and Bert are technically correct but what you're correct about doesn't matter.

Should node cause an exception on accessing this prototype which many people expect to be there?

The answer is obviously "no" only because it's much easier to make it not a problem that anyone ever sees than it is to explain this to everyone who gets this error.

If you reply with another email explaining to me how JavaScript works I'm seriously going to flip out.

-Mikeal

Let me elaborate on my reservations a little more:

* Calling .hasOwnProperty() (or any other prototype method) on an object that's used as a hash table and where the keys are defined outside of the program's control is an anti pattern. People shouldn't do it. The question is really whether node wants to get in the way of the user when he tries to do it anyway. That's debatable - I could live with fixing the prototype. But really, if I were to redo node, I would make all of these guys - process.env, http headers, querystring args - prototype-less object.

* process.env does not in any way behave like a normal object. For example all values are coerced to string, and setting a value to "" (empty string) might actually delete the key. Also, on Windows, keys are case insensitive; changing that is going to break much more than it fixes. There's probably more weirdness that I am not even aware of, which is all caused by the fact that the environment *is* not a JS object. The "proper" way to do it would probably be to remove `process.env` and expose the functions `process.setenv()` and `process.getenv()`, but the way it works now is too damn convenient to remove. People should just accept the fact that process.env behaves a little different sometimes, and if you really need JS object semantics, make a copy of it.

- Bert

[Isaac Schlueter]

Bert,

I'm with you on setenv/getenv being better. Maybe we can add those
also, and those who value correctness will use them.

In the meantime,
https://github.com/joyent/node/commit/e3074689f501eea413c29b99defac29659a2b615
fixes 90% of the weirdness. Having process.env behave like an object
is indeed too damn convenient, but if we're going to do that, we
should accept that it's worth giving up a slight amount of correctness
in exchange for convenience.

[Brandon Benvie]

What this really indicates is, given a time machine, is that process.env should have been implemented as get and set functions. Object.prototype.getOwnProperty.call(obj, key) will work correctly on any JS object, and these days it'll actually work correctly on most/all DOM objects in a browser. So even setting the object as having no prototype doesn't really solve the problem. The problem is that it's not a JS object in any sense of the word, nor has an API that fulfills the contracts that JS objects are supposed to fill.

[Brandon Benvie]

(oh Bert said most of that)

[Rick Waldron]

I've been following this conversation closely, but one thing that I'm still unclear about is _why_ process.env not a JS object (by new Object definition, that is).

There are some obvious guesses, but I'm mostly interested in actual documentation or historical fact, and not at all interested in opinion or more guesses - thanks!

-Rick

On Tuesday, June 26, 2012 at 9:50 PM, Brandon Benvie wrote:

(oh Bert said most of that)

--

[Ben Noordhuis]

On Wed, Jun 27, 2012 at 4:00 AM, Rick Waldron <waldro...@gmail.com> wrote:
> I've been following this conversation closely, but one thing that I'm still
> unclear about is _why_ process.env not a JS object (by new Object
> definition, that is).
>
> There are some obvious guesses, but I'm mostly interested in actual
> documentation or historical fact, and not at all interested in opinion or
> more guesses - thanks!

Because it's not. It's a front for a bunch of libc functions. It just
looks like an object, mostly.

Here is the original commit[1]. Before that, process.env was a simple
copy of the environment (granted, as a pure JS object). I didn't want
to break the interface so I hacked up the thing we have today.

[1] https://github.com/joyent/node/commit/b4def48

[Rick Waldron]

Thanks for info - certainly appreciated

Rick

[Brandon Benvie]

Just as a distraction from work I should be doing instead, I made a module that exports the EnvGetter, EnvSetter, EnvEnumerator, and EnvDeleter as functions. It also optionally, if Proxy is available, exports an Environment constructor that creates objects that are similar to process.env but more closely follow semantics of real objects. I may expand it to support management of env of other process, but this is more complicated and for now it's just an experiment that sticks to node's existing functionality.

https://github.com/Benvie/environment 

[Isaac Schlueter]

Brandon,

I like this! It's a shame that it requires --harmony. When/if Proxy
lands in our normal V8 by default, we should consider replacing
process.env with this.

[Brandon Benvie]

Yeah this is definitely one of those places where proxies show their real value. Being able to represent a heap external interface without having to leave JS except for the very minimum amount required. With the Direct Proxies API it'll go from "doable" to "trivial" to implement virtual objects that mostly obey the rules of regular objects and don't blow up if you try to use that as a prototype or use some rarely used but normal JS API (the amount of C++ modules that explode if you do something like Object.getOwnPropertyNames(Object.getPrototypeOf(cplusplusModuleObject)) is actually quite ridiculous).

An interesting use-case I want to try out is that of representing near-synced objects between parent/child/sibling processes. process.env is a good example here as well because it's not generally time critical, but still useful... "near objecst". Something that is usually around a single event loop turn away, because it's out of process or in a js external memory storage, or not in the JS heap for whatever reason, but close enough that the limitation is simply having to post a callback to get at it.

Sometimes these things are time critical and C++ apis support that, but usually you just build/use an async API around it. These objects are close enough though that with some creative synchronization a useful proxy interface could be provided that is "close enough" to provide the best of both worlds. A child's process process.env would be an example where the gap could be bridged by a proxy that provided local in-heap access and was semi-lazily synced as needed. This captures the best of both worlds I think, offloading the need to treat an API as asynchronous without resorting to those things which shall not be named.

[Jorge]

On 30/06/2012, at 04:46, Brandon Benvie wrote:
> (...) This captures the best of both worlds I think, offloading the need to treat an API as asynchronous without resorting to those things which shall not be named.

What, what? Which things?
--
Jorge.

[Brandon Benvie]

"Unterminated string literals ಠ_ಠ

[Alan Gutierrez]

On 6/30/12 2:17 AM, Brandon Benvie wrote:
> "Unterminated string literals ಠ_ಠ

I don't understand this at all. I'd really appreciate a link, because
all Google talks about are errors. How are Unterminated string literals
"offloading the need to treat an API as asynchronous".

--
Alan Gutierrez - @bigeasy

[Brandon Benvie]

Mission accomplished?"