Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #30586 > unrolled thread

Re: not "autovivification", but ...?

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: not "autovivification", but ...? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-05-31 14:11 +0200
    Re: not "autovivification", but ...? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-06-01 07:51 -0700
      Re: not "autovivification", but ...? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-01 18:46 +0200

#30586 — Re: not "autovivification", but ...?

On 31.05.2016 at 13:51, Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> "use strict"; this.b = 1;
> 
>   And I wonder, why in strict mode in the outmost scope, when
> 
> b = 1
> 
>   is forbidden (given that »this.b« does not exist)
> 
> this.b = 1
> 
>   is allowed. What is the rationale for allowing it with »this.«?

`this` is not special in this regard;  you can assign to undefined
properties of *any* object.

Also consider that accessing undefined properties of an object yield
`undefined` (but not an error), so it appears to be logical to allow
assigning another value to such undefined properties.

-- 
Christoph M. Becker

[toc] | [next] | [standalone]

#30593

On Tuesday, May 31, 2016 at 7:11:39 AM UTC-5, Christoph M. Becker wrote:
> On 31.05.2016 at 13:51, Stefan Ram wrote:
> 
> > (Stefan Ram) writes:
> >> "use strict"; this.b = 1;
> > 
> >   And I wonder, why in strict mode in the outmost scope, when
> > 
> > b = 1
> > 
> >   is forbidden (given that »this.b« does not exist)
> > 
> > this.b = 1
> > 
> >   is allowed. What is the rationale for allowing it with »this.«?
> 
> `this` is not special in this regard;  you can assign to undefined
> properties of *any* object.

Most, not any. For example: [1]

> Also consider that accessing undefined properties of an object yield
> `undefined` (but not an error), so it appears to be logical to allow
> assigning another value to such undefined properties.

That does not follow. Ex:

//assume this function is defined in a 3rd party library
function getSomeObject(){
  return Object.seal({
    hello: "world"
  })
}

//in your code somewhere:
var someObject = getSomeObject()

typeof someObject.hello // string

typeof someObject.hola // undefined

someObject.hola = "mundo"

typeof someObject.hola // undefined


[1] <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/seal>

[toc] | [prev] | [next] | [standalone]

#30595

On 01.06.2016 at 16:51, Michael Haufe (TNO) wrote:

> On Tuesday, May 31, 2016 at 7:11:39 AM UTC-5, Christoph M. Becker wrote:
>
>> `this` is not special in this regard;  you can assign to undefined
>> properties of *any* object.
> 
> Most, not any. For example: [1]
> 
>> Also consider that accessing undefined properties of an object yield
>> `undefined` (but not an error), so it appears to be logical to allow
>> assigning another value to such undefined properties.
> 
> That does not follow. Ex:
> 
> //assume this function is defined in a 3rd party library
> function getSomeObject(){
>   return Object.seal({
>     hello: "world"
>   })
> }
>
> [1] <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/seal>

Thanks for pointing that out.  I most certainly should catch up with ES
5.1 ASAP. :)

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web