process.env instanceof Object === true
typeof process.env.hasOwnProperty === undefined
Bug?
--
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 "no
On Fri, Jun 22, 2012 at 6:04 PM, Martin Thomson
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
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 meth
On Fri, Jun 22, 2012 at 7:22 PM, Bert Belder 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.
> 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.
On Fri, Jun 22, 2012 at 4:58 PM, Ben Noordhuis wrote:
>
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
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) ? :-)
On Friday, June 22, 2012 8:02:47 PM UTC-4, Isaac Schlueter wrote:
>
> 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 htt
Hi,
$ node
> noProto = Object.create(null);
{}
> noProto instanceof Object
false
`process.env instanceof Object` should be `false`
if it has no prototype.
On Fri, 22 Jun 2012 17:04:02 -0700, Mikeal Rogers
wrote:
> process.env should be a real js object, or at least act like one.
>
> if we
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++ st
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.cr
yes, the language has warts, what is your point?
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.
>
> On Jun 23, 2012, at 2:04 AM, Mikeal Rogers wrote:
>
>> process.env should be a real js object, or at least
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 a
On Sat, Jun 23, 2012 at 6:39 PM, Marco Rogers 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 li
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 expe
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
o
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.
On Jun 23, 2012, at June 23, 20125:30 PM, Jorg
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?
>>>
>>>
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
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
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,
On Sun, Jun 24, 2012 at 3:52 AM, Isaac Schlueter 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, process.getEnv(key) -> String,
> and process.putEnv(key, var, clobber=true) -> Boole
On 24/06/2012, at 04:09, Ben Noordhuis wrote:
> On Sun, Jun 24, 2012 at 3:52 AM, Isaac Schlueter 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, process.getEnv(key) -> String,
>>
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
> co
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
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 i
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.
(oh Bert said most of that)
--
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 nodejs@googlegr
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
On Wed, Jun 27, 2012 at 4:00 AM, Rick Waldron 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
> d
On Tuesday, June 26, 2012 at 10:23 PM, Ben Noordhuis wrote:
> On Wed, Jun 27, 2012 at 4:00 AM, Rick Waldron 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).
> >
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 mo
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.
On Thu, Jun 28, 2012 at 8:08 AM, Brandon Benvie
wrote:
> Just as a distraction from work I should be doing instead, I made a modu
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
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.
--
Job Board: http://jobs.nodejs.org/
P
"Unterminated string literals ಠ_ಠ
--
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 nodejs@go
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
Mission accomplished?"
--
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 nodejs@googlegroups.
38 matches
Mail list logo
