Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #22564 > unrolled thread
| Started by | "Tony Johansson" <johansson.andersson@telia.com> |
|---|---|
| First post | 2014-01-11 13:08 +0100 |
| Last post | 2014-01-11 23:10 +0700 |
| Articles | 9 — 5 participants |
Back to article view | Back to comp.lang.javascript
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
| From | "Tony Johansson" <johansson.andersson@telia.com> |
|---|---|
| Date | 2014-01-11 13:08 +0100 |
| Subject | Why 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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-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]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2014-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]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-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]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-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]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-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]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2014-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]
| From | JJ <duh@nah.meh> |
|---|---|
| Date | 2014-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