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
On Jun 23, 2012, at June 23, 20125:51 PM, 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
