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


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

Why do I have to use the keyword this in my Employee example

Started by"Tony Johansson" <johansson.andersson@telia.com>
First post2014-01-11 13:08 +0100
Last post2014-01-11 23:10 +0700
Articles 9 — 5 participants

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


Contents

  Why do I have to use the keyword this in my Employee example "Tony Johansson" <johansson.andersson@telia.com> - 2014-01-11 13:08 +0100
    Re: Why do I have to use the keyword this in my Employee example Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-11 16:37 +0100
    Re: Why do I have to use the keyword this in my Employee example John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-11 15:58 +0000
      Re: Why do I have to use the keyword this in my Employee example Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-11 18:02 +0100
        Re: Why do I have to use the keyword this in my Employee example Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-11 20:07 +0100
          Re: Why do I have to use the keyword this in my Employee example Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-12 21:15 +0100
            Re: Why do I have to use the keyword this in my Employee example Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-12 21:51 +0100
          Re: Why do I have to use the keyword this in my Employee example John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-14 09:56 +0000
    Re: Why do I have to use the keyword this in my Employee example JJ <duh@nah.meh> - 2014-01-11 23:10 +0700

#22564 — Why do I have to use the keyword this in my Employee example

From"Tony Johansson" <johansson.andersson@telia.com>
Date2014-01-11 13:08 +0100
SubjectWhy do I have to use the keyword this in my Employee example
Message-ID<larc8g$s3c$1@dont-email.me>
The kyword this is always refering to the owner.
In this Employee example the owner must be window.
I userstand this for example when I want to change color for  this html 
control I pass the controlitself to the event handler ChangeColor
<input id="Button1" type="button" value="button" 
onclick="ChangeColor(this)"

<script type="text/javascript">
   function Employee(first, last)
   {
       var _firstName = first;
       var _lastName = last;

       this.set_FirstName = function (first)
       {
           _firstName = first;
       }

       this.get_FirstName = function ()
       {
           return _firstName;
       }


       this.set_LastName = function (last)
       {
           _lastName = last;
       }

       this.get_LastName = function ()
       {
           return _lastName;
       }
   }

   function Foo()
   {
        var emp = new Employee("Nisse", "Hult");
        var name = emp.get_FirstName() + " " + emp.get_LastName();
        emp.set_FirstName("Olle");
        emp.set_LastName("Ås");
        var name2 = emp.get_FirstName() + " " + emp.get_LastName();
   }
 </script>

//Tony 

[toc] | [next] | [standalone]


#22566

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-11 16:37 +0100
Message-ID<3363070.6bLXA3eQba@PointedEars.de>
In reply to#22564
Tony Johansson wrote:

> The kyword this is always refering to the owner.

No, it always evaluates to the “this” value of the execution context.

> In this Employee example the owner must be window.

No, the new “Employee” instance.

> I userstand this for example when I want to change color for  this html 
> control I pass the controlitself to the event handler ChangeColor
> <input id="Button1" type="button" value="button" 
> onclick="ChangeColor(this)"

You have not posted a “ChangeColor” function.

> […]
>    function Employee(first, last)
>    {
>        var _firstName = first;
>        var _lastName = last;
> 
>        this.get_FirstName = function ()
>        {
>            return _firstName;
>        }
> […]
>    }
> 
>    function Foo()

This function is probably never called as a constructor (because that would 
not make sense); avoid the leading capital letter.

>    {
>         var emp = new Employee("Nisse", "Hult");
>         var name = emp.get_FirstName() + " " + emp.get_LastName();
> […]
>    }

I find your indentation excessive, especially for Usenet; two spaces per 
level should suffice.  YMMV.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22567

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2014-01-11 15:58 +0000
Message-ID<hdq2d9p4tjse2t0isfv010f2m9f0fn7gdl@4ax.com>
In reply to#22564
On Sat, 11 Jan 2014 13:08:29 +0100, "Tony Johansson"
<johansson.andersson@telia.com> wrote:

Please put the question in the text, not just in the Subject.

>The kyword this is always refering to the owner.
>In this Employee example the owner must be window.
>I userstand this for example when I want to change color for  this html 
>control I pass the controlitself to the event handler ChangeColor
><input id="Button1" type="button" value="button" 
>onclick="ChangeColor(this)"
>
><script type="text/javascript">
>   function Employee(first, last)
>   {
>       var _firstName = first;
>       var _lastName = last;
>
Those are *local* variables, hidden inside the Employee function. They
won't exist any more once Employee has returned.

If you want _firstName and _lastName to be global variables you have
to put the var statements outside any function body. Then every
employee in the program has the same name.

If you want the Employee function to be a constructor, and for every
employee object to have its own separate name, then you have to use
'this.' instead of 'var'.

Personally, I prefer to write
  emp.firstName
rather than
  emp.get_FirstName()

  John

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


#22569

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-11 18:02 +0100
Message-ID<52d1792f$0$6555$9b4e6d93@newsspool4.arcor-online.net>
In reply to#22567
John Harris wrote:

> On Sat, 11 Jan 2014 13:08:29 +0100, "Tony Johansson"
> <johansson.andersson@telia.com> wrote:
> 
>> <script type="text/javascript">
>>   function Employee(first, last)
>>   {
>>       var _firstName = first;
>>       var _lastName = last;
>>
> Those are *local* variables, hidden inside the Employee function. They
> won't exist any more once Employee has returned.

That's not quite right.  Actually, the variables are part of the
environment of the methods of Employee, if Employee is invoked as
constructor (what happens in function Foo()).

-- 
Christoph M. Becker

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


#22573

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-11 20:07 +0100
Message-ID<1590346.McO4MUtrrQ@PointedEars.de>
In reply to#22569
Christoph Michael Becker wrote:

> John Harris wrote:
>> On Sat, 11 Jan 2014 13:08:29 +0100, "Tony Johansson"
>> <johansson.andersson@telia.com> wrote:
>> 
>>> <script type="text/javascript">
>>>   function Employee(first, last)
>>>   {
>>>       var _firstName = first;
>>>       var _lastName = last;
>>>
>> Those are *local* variables, hidden inside the Employee function. They
>> won't exist any more once Employee has returned.
> 
> That's not quite right.  Actually, the variables are part of the
> environment of the methods of Employee, if Employee is invoked as
> constructor (what happens in function Foo()).

Not quite correct; this applies only to these methods of Employee 
_instances_ and other functions defined in the context of Employee().
Key word: closure.

The methods of Employee instances here are “privileged“ and the variables 
are “private” (terms coined by Douglas Crockford, IIRC), because only those 
methods can access those variables/pseudo-properties.  It is the closest 
equivalent to private/protected properties in class-based OOP.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22584

FromChristoph Michael Becker <cmbecker69@arcor.de>
Date2014-01-12 21:15 +0100
Message-ID<52d2f7f4$0$9522$9b4e6d93@newsspool1.arcor-online.net>
In reply to#22573
Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> John Harris wrote:
>>> On Sat, 11 Jan 2014 13:08:29 +0100, "Tony Johansson"
>>> <johansson.andersson@telia.com> wrote:
>>>
>>>> <script type="text/javascript">
>>>>   function Employee(first, last)
>>>>   {
>>>>       var _firstName = first;
>>>>       var _lastName = last;
>>>>
>>> Those are *local* variables, hidden inside the Employee function. They
>>> won't exist any more once Employee has returned.
>>
>> That's not quite right.  Actually, the variables are part of the
>> environment of the methods of Employee, if Employee is invoked as
>> constructor (what happens in function Foo()).
> 
> Not quite correct; this applies only to these methods of Employee 
> _instances_ and other functions defined in the context of Employee().
> Key word: closure.

That is what I meant to say, but failed to do.  Thanks for the
clarification.

> The methods of Employee instances here are “privileged“ and the variables 
> are “private” (terms coined by Douglas Crockford, IIRC), because only those 
> methods can access those variables/pseudo-properties.  It is the closest 
> equivalent to private/protected properties in class-based OOP.

AIUI, this technique has a memory overhead, however, as references to
the functions would have to be stored once per object instance (opposed
to functions referenced from properties of the prototype object).

-- 
Christoph M. Becker

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


#22585

FromThomas 'PointedEars' Lahn <PointedEars@web.de>
Date2014-01-12 21:51 +0100
Message-ID<13124040.1SXmGGuGdH@PointedEars.de>
In reply to#22584
Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> The methods of Employee instances here are “privileged“ and the variables
>> are “private” (terms coined by Douglas Crockford, IIRC), because only
>> those methods can access those variables/pseudo-properties.  It is the
>> closest equivalent to private/protected properties in class-based OOP.
> 
> AIUI, this technique has a memory overhead, however, as references to
> the functions would have to be stored once per object instance (opposed
> to functions referenced from properties of the prototype object).

Yes, it is a tradeoff.  Someone had suggested privileged *prototype* methods 
instead, but that only helps if all instances should share the variable 
values.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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


#22613

FromJohn Harris <niam@jghnorth.org.uk.invalid>
Date2014-01-14 09:56 +0000
Message-ID<id2ad9ddit2f9igva84q80incbugm7o1uo@4ax.com>
In reply to#22573
On Sat, 11 Jan 2014 20:07:20 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Christoph Michael Becker wrote:
>
>> John Harris wrote:
>>> On Sat, 11 Jan 2014 13:08:29 +0100, "Tony Johansson"
>>> <johansson.andersson@telia.com> wrote:
>>> 
>>>> <script type="text/javascript">
>>>>   function Employee(first, last)
>>>>   {
>>>>       var _firstName = first;
>>>>       var _lastName = last;
>>>>
>>> Those are *local* variables, hidden inside the Employee function. They
>>> won't exist any more once Employee has returned.
>> 
>> That's not quite right.  Actually, the variables are part of the
>> environment of the methods of Employee, if Employee is invoked as
>> constructor (what happens in function Foo()).
>
>Not quite correct; this applies only to these methods of Employee 
>_instances_ and other functions defined in the context of Employee().
>Key word: closure.
>
>The methods of Employee instances here are “privileged“ and the variables 
>are “private” (terms coined by Douglas Crockford, IIRC), because only those 
>methods can access those variables/pseudo-properties.  It is the closest 
>equivalent to private/protected properties in class-based OOP.

It's a pointless thing to do here though. Anything can use a set...()
call to put any values it likes in _firstName and _lastName, including
null or undefined. 

  John

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


#22568

FromJJ <duh@nah.meh>
Date2014-01-11 23:10 +0700
Message-ID<u8hl4jwiqrcc$.cnc7nhasz6xd$.dlg@40tude.net>
In reply to#22564
On Sat, 11 Jan 2014 13:08:29 +0100, Tony Johansson wrote:
> The kyword this is always refering to the owner.
> In this Employee example the owner must be window.
> 
> <script type="text/javascript">
>    function Employee(first, last)
>    {
>        var _firstName = first;
>        var _lastName = last;
> 
>        this.set_FirstName = function (first)
>        {
>            _firstName = first;
>        }
> 
>        this.get_FirstName = function ()
>        {
>            return _firstName;
>        }
> 
>        this.set_LastName = function (last)
>        {
>            _lastName = last;
>        }
> 
>        this.get_LastName = function ()
>        {
>            return _lastName;
>        }
>    }
> 
>    function Foo()
>    {
>         var emp = new Employee("Nisse", "Hult");
>         var name = emp.get_FirstName() + " " + emp.get_LastName();
>         emp.set_FirstName("Olle");
>         emp.set_LastName("Ås");
>         var name2 = emp.get_FirstName() + " " + emp.get_LastName();
>    }
>  </script>
> 
> //Tony

"this" refers to the (Employee) object being created because Employee is
called as a constructor rather than a function.

<script>
function func(){
  return this;
}
var a = new func();
console.log( a === window ); //false
var a = func();
console.log( a === window ); //true
</script>

> I userstand this for example when I want to change color for  this html 
> control I pass the controlitself to the event handler ChangeColor
> <input id="Button1" type="button" value="button" 
> onclick="ChangeColor(this)"

That's different. That "this" will always refer to the element (the INPUT).

[toc] | [prev] | [standalone]


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


csiph-web