calling a method from a method

[torbs]

Hi

I have a a function with several methods. For simplicity it looks a bit
like this:
super.prototype.aProperty="HELLO";
super.prototype.returnValue = function () {

return 2;

}

super.prototype.aMethod = function () {

var a = this.returnValue()
alert(a)

}

function super() { }

theObject= new super;

theObject.aMethod();

How can I call a method from within a method? In other word how can I
make the "this" keyword refere to the object and not the method?

Tor

[Touffy]

On 2006-04-21 17:10:09 +0200, "torbs" <to********@gmail.com> said:

Hi

I have a a function with several methods. For simplicity it looks a bit
like this:
super.prototype.aProperty="HELLO";
super.prototype.returnValue = function () {

return 2;

}

super.prototype.aMethod = function () {

var a = this.returnValue()
alert(a)

}

function super() { }
you should write the constructor declaration _before_ assigning anyting
to its prototype. Moreover, class names in JavaScript traditionnally
begin with a capital.
And you should definitely NOT name a function "super" since it is a
reserved word.
theObject= new super;
you must call the constructor :

theObject = new Super()

not just write its name.
theObject.aMethod();

How can I call a method from within a method? In other word how can I
make the "this" keyword refere to the object and not the method?
by default, this actually refers to the owner of the method, so you're
lucky, you don"t have to do anything to achieve that result.
However you can't refer to the owner of the owner of the method, for
instance, unless you have set a property to reference it.

Tor

--
David Junger

[torbs]

Thank you!

As it turns out this was not really my problem, but I will create a
mnew post for that.

Tor

[Thomas 'PointedEars' Lahn]

Touffy wrote:

On 2006-04-21 17:10:09 +0200, "torbs" <to********@gmail.com> said:

I have a a function with several methods. For simplicity it looks a bit
like this:

super.prototype.aProperty="HELLO";
super.prototype.returnValue = function () {

return 2;

}

super.prototype.aMethod = function () {

var a = this.returnValue()
alert(a)

}

function super() { }
you should write the constructor declaration _before_ assigning anyting
to its prototype.

I once thought so, too, but in fact, the order is not significant
here as variable instantiation takes place before execution.
Moreover, class names in JavaScript traditionnally begin with a capital.
Traditionally, there are no classes in JavaScript. It is a programming
language with prototype-based inheritance. But the statement holds true
in that sense: constructors should have identifiers that start with a
capital letter to distinguish them from other methods easily.
And you should definitely NOT name a function "super" since it is a
reserved word.

True.

theObject= new super;

you must call the constructor :

theObject = new Super()
not just write its name.

Ignoring the case, both statements are semantically equivalent.
PointedEars

[Touffy]

On 2006-04-21 18:36:02 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> said:

Touffy wrote:

Moreover, class names in JavaScript traditionnally begin with a capital.
Traditionally, there are no classes in JavaScript. It is a programming
language with prototype-based inheritance. But the statement holds true
in that sense: constructors should have identifiers that start with a
capital letter to distinguish them from other methods easily.

an objet created by a constructor is an instance of the class defined
by that constructor, as demonstrated by the 'instanceof' operator.
Though there is no formal class declaration in ECMAScript 3, the
concept of class is therefore present in JavaScript.
I agree that your wording is, however, more precise.

theObject= new super;

you must call the constructor :

theObject = new Super()
not just write its name.

Ignoring the case, both statements are semantically equivalent.

I had always believed you had to call the constructor. I won't use this
much since I usually pass arguments to a constructor, but thanks anyway.
--
David Junger

[Michael Winter]

On 21/04/2006 16:10, torbs wrote:

[snip]

super.prototype.aMethod = function () {

var a = this.returnValue()
alert(a)

}
[snip]
How can I call a method from within a method?
Aside from the issue of using 'super' as an identifier (it's a future
reserved word: don't use it), exactly as you have done above.
In other word how can I make the "this" keyword refere to the object
and not the method?

The this operator value changes according to how a function is called.
I've written about this a few times in the past. Please read

Subject: Re: How do I properly pass a parameter to a
parameterized event handler in a loop?
Date: Sun, 01 Jan 2006 21:07:09 GMT
Message-ID: 1wXtf.18275$[e-mail]

<http://www.google.com/url?sa=D&q=http://groups.google.co.uk/group/comp.lang.javascript/browse_frm/thread/d77f3051f3e80a8c/ec26cd885e01c292%23ec26cd885e01c292>

and see if that helps you.

Feel free to ask further questions.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Michael Winter]

On 21/04/2006 18:29, Touffy wrote:

On 2006-04-21 18:36:02 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> said:
[snip]

Traditionally, there are no classes in JavaScript. It is a
programming language with prototype-based inheritance.

[snip]
an objet created by a constructor is an instance of the class defined
by that constructor, [...]
I won't repeat what Thomas wrote, but I will reassert it.
as demonstrated by the 'instanceof' operator.
The instanceof operator is not defined in terms of classes. It calls the
internal [[HasInstance]] method of the right-hand operand, which itself
examines the prototype chain (the internal [[Prototype]] property) of
the left-hand operand.
Though there is no formal class declaration in ECMAScript 3, the
concept of class is therefore present in JavaScript.
It might be convenient for some to think in terms of classes, but not
accurate.

[new Identifier vs. new Identifier()]
I had always believed you had to call the constructor. [...]

The empty argument list is implied. The new operator invokes the
internal [[Construct]] method, which in turn calls [[Call]].

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Touffy]

On 2006-04-21 19:57:16 +0200, Michael Winter <m.******@blueyonder.co.uk> said:

On 21/04/2006 18:29, Touffy wrote:

On 2006-04-21 18:36:02 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> said:

[snip]

Traditionally, there are no classes in JavaScript. It is a
programming language with prototype-based inheritance.
[snip]

an objet created by a constructor is an instance of the class defined
by that constructor, [...]

I won't repeat what Thomas wrote, but I will reassert it.

as demonstrated by the 'instanceof' operator.

The instanceof operator is not defined in terms of classes. It calls
the internal [[HasInstance]] method of the right-hand operand, which
itself examines the prototype chain (the internal [[Prototype]]
property) of the left-hand operand.

notwithstanding the inner workings, the word "instanceof" is also
composed of three English words that suggest a relationship usually
found with "classes". That was my point.
Though there is no formal class declaration in ECMAScript 3, the
concept of class is therefore present in JavaScript.

It might be convenient for some to think in terms of classes, but not accurate.

It might be convenient, and I don't see any problem that could arise
from using the *concept* of class in JavaScript (knowing that some
features of a "class", such as inheritance, may not work as in other
languages). Actually, it's even quite accurate. So long as your
definition of a class does not include specific language features.
If I define "an instance of a class" as an object created by the
constructor with the name of that class, then my use of the "class"
abtraction is very accurate.
Similarly, a "class method" is a method of the constructor Function
object, that I even call a "static" method even though "static" is not
a JavaScript primitive yet.

I must agree that there is no word in the language to say "class", but
we're not speaking JavaScript when describing how a script works (AFAIK
we're mostly using English, and in a programming context, the word
"class" can surely be applied to JavaScript - although it may be useful
to have a precise, common definition online somewhere to make sure
there is no possible confusion).

--
David Junger

[Thomas 'PointedEars' Lahn]

Touffy wrote:

[...] Thomas 'PointedEars' Lahn [...] said:

Touffy wrote:

Moreover, class names in JavaScript traditionnally begin with a capital. Traditionally, there are no classes in JavaScript. It is a programming
language with prototype-based inheritance. But the statement holds true
in that sense: constructors should have identifiers that start with a
capital letter to distinguish them from other methods easily.

an objet created by a constructor is an instance of the class defined
by that constructor, as demonstrated by the 'instanceof' operator.

No, it is not. You, too, try to impose class-based terms and thinking on
what is, with the exceptions described below, an object-oriented (or
object-based) programming language with _prototype-based_ inheritance.

Objects inherit from other objects, not from classes. In /that/ sense only,
a JS/ECMAScript object can be called an instance; but not of a class, a
rather abstract data structure, but of another already existing object.
[See Michael's followup about the `instanceof' operation.] The prototype
chain is similar, but not at all equal to a class hierarchy.

Search the archives, and read the ECMAScript specification (Ed. 3 Final)
thoroughly. See also <URL:http://crockford.com/javascript/javascript.html>
(although Douglas' views about quality are debatable [except when it comes
to books], certainly he has a point about the workings of the language).
Though there is no formal class declaration in ECMAScript 3, the
concept of class is therefore present in JavaScript.
You are wrong. The concept of classes is formally defined and present in
JavaScript 2.0, a Netscape proposal that has no implementation but the
Epimetheus test implementation yet. It is also defined and present in
Netscape's ECMAScript Edition 4 proposal to the responsible ECMA-WG, that
is not a specification yet. And it is defined and present in JScript 7.0+
(.NET), implemented only server-side (AFAIK). Not in any previous version
or edition, which happen to be the versions and editions widely implemented
client-side (in HTML user agents, colloq.: Web browsers).
I agree that your wording is, however, more precise.
Your wording is simply incorrect.

theObject= new super;

you must call the constructor :

theObject = new Super()
not just write its name.

Ignoring the case, both statements are semantically equivalent.

I had always believed you had to call the constructor.

A constructor is not [[Call]]ed like a usual method. It is [[Call]]ed
when it is [[Construct]]ed due to a NewExpression. So it /is/ called
(differently) then, even though the argument list was not provided.
See ECMAScript Ed. 3, subsections 8.6.2 (Built-in Methods) and 13.2.2
([[Construct]]).
I won't use this much since I usually pass arguments to a constructor,
Me too.
but thanks anyway.

You are welcome.
PointedEars

[John G Harris]

In article <11****************@PointedEars.de>, Thomas 'PointedEars'
Lahn <Po*********@web.de> writes

Touffy wrote:
<snip>

an objet created by a constructor is an instance of the class defined
by that constructor, as demonstrated by the 'instanceof' operator.

No, it is not. You, too, try to impose class-based terms and thinking on
what is, with the exceptions described below, an object-oriented (or
object-based) programming language with _prototype-based_ inheritance.

In English, and in Mathematics, it is perfectly proper to talk about the
class of objects that can be created by the constructor X, and to then
refer to them as the X class of objects.

What's different about javascript is that you can alter objects so that
two X class objects have no properties in common and different prototype
chains. This is unlike languages such as Java and C++ where the source
code provides class *definitions* that are enforced by the compiler and
can't be changed while the program is running.

You're right to regard the use of the word 'class' as dangerous, but not
to say that it can't be used properly.

Objects inherit from other objects, not from classes.

<snip>

This is only half right.

When methods are properties of prototype objects you can say they are
inherited from (prototype) objects. (It doesn't have to be done this
way. Javascript is a very flexible language.)

However, data is always held in the instance objects, otherwise you
couldn't have different values in different objects. It's the data
format, the property names and value types, that are inherited. The same
is true in Java and C++. How those properties get there is up to the
programmer. Again, javascript is a very flexible language.

John
--
John Harris

[VK]

John G Harris wrote:

What's different about javascript is that you can alter objects so that
two X class objects have no properties in common and different prototype
chains. This is unlike languages such as Java and C++ where the source
code provides class *definitions* that are enforced by the compiler and
can't be changed while the program is running.
At least in Java they can by alternating classLoader and Class
constructor - but it is much closer to the hacking than to the
conventional programming. I would say that the difficulties to alter
constructor in encapsulated languages and easyness to do so in
JavaScript/JScript is the only real principal difference (in this
aspect). The coding style and coding approaches are just the
consequences of the above.
You're right to regard the use of the word 'class' as dangerous, but not
to say that it can't be used properly.

Not really "dangerous" and most definitely not a "taboo word". The
latter would be really redicilous. First of all it is not a primitive
tribe here to call a bear "Him How Likes the Honey" or class(oid)
"Object to Create Other Objects with Predefined Members" :-) Secondly
the term "class" is officially used in MSDN documentation in reference
to function-constructor: and not only for JScript.Net but JScript 5.x
either. So this hole is wide open any way :-)

The potential "hurm" can be for C++ / Java 'ers beginning to use
JavaScript - as they may miss the point that it is rather another
environment - and get silly in their coding.
"There Class - here Class, all like at home. So where is my destructor?
(memory cleaner, integer allocator, yours to continue)".

[Lasse Reichstein Nielsen]

John G Harris <jo**@nospam.demon.co.uk> writes:

In article <11****************@PointedEars.de>, Thomas 'PointedEars'
Lahn <Po*********@web.de> writes In English, and in Mathematics, it is perfectly proper to talk about the
class of objects that can be created by the constructor X, and to then
refer to them as the X class of objects.
It's equally possible to talk about the group of objects, or the set
of objects, that are created through (not by) a constructor.
It is still signficantly different from the use of the word "class"
in class based languages, and using the word about Javascript is
bound to lead people, almost always including the people using it,
to attribute behavior or relations to objects that are not there.
What's different about javascript is that you can alter objects so that
two X class objects have no properties in common and different prototype
chains.
I.e., they have nothing in common inside the computer. The only
commonality is that a person has decided to group them both in the "X
class" of objects.
This is unlike languages such as Java and C++ where the source
code provides class *definitions* that are enforced by the compiler and
can't be changed while the program is running.
Very different.
You're right to regard the use of the word 'class' as dangerous, but not
to say that it can't be used properly.
You can do things in Javascript that resemble class based programming
on the surface, but below it is subtly different. Using the word properly,
without assuming properties of class based languages, and without
confuzing the listener, is so hard that I suggest inventing a new word
over using "class".

Objects inherit from other objects, not from classes.

<snip>

This is only half right.

No, it's completely right. There are no classes. Objects inherit
from other objects. Constructor functions double as a vessel for
the prototype object and code that initializes the new object,
but after that has happened, the new object need not have any
relation to that function any more.
When methods are properties of prototype objects you can say they are
inherited from (prototype) objects. (It doesn't have to be done this
way. Javascript is a very flexible language.)
An object has properties. Some of these properties are set on the
object itself, others are inherited from other objects in the object's
prototype chain. That's all the inheritance Javascript has.
However, data is always held in the instance objects, otherwise you
couldn't have different values in different objects.
You write this as if there is a difference between prototype objects
and instance objects. There are not. Any object can be used as a
prototype for another object.
It's the data format, the property names and value types, that are
inherited.
What data format? What value types?

What is inherited in Javascript are *properties*. Not even just their
name and their value, but the property itself. If you change value of
the inherited property on the prototype object, then the inheriting
object inherits the property with its new value too.
The same is true in Java and C++.
But it is not true in Javascript.
How those properties get there is up to the programmer. Again,
javascript is a very flexible language.

It is. You can add properties to an object, you can add properties
to one of its prototypes, and you can create new objects using the
object as a prototype.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

In article <d5**********@hotpop.com>, Lasse Reichstein Nielsen
<lr*@hotpop.com> writes

John G Harris <jo**@nospam.demon.co.uk> writes:

<snip>

What's different about javascript is that you can alter objects so that
two X class objects have no properties in common and different prototype
chains.

I.e., they have nothing in common inside the computer. The only
commonality is that a person has decided to group them both in the "X
class" of objects.

What is common is that they were all created by doing new X(). People
should still be able to talk about these objects. Even if the programmer
is completely confused the mess is still restricted to the "X class of
objects"; the confusion doesn't include objects created by doing new
Date(), for instance.
<snip>

However, data is always held in the instance objects, otherwise you
couldn't have different values in different objects.

You write this as if there is a difference between prototype objects
and instance objects. There are not. Any object can be used as a
prototype for another object.

It's the data format, the property names and value types, that are
inherited.

What data format? What value types?

What is inherited in Javascript are *properties*. Not even just their
name and their value, but the property itself. If you change value of
the inherited property on the prototype object, then the inheriting
object inherits the property with its new value too.

<snip>

I'm surprised at you saying that. Suppose you have Vehicle objects and
Car objects, and you want cars to 'inherit' from vehicles. Suppose also
that each Vehicle object has a weight, e.g 2.5 tonnes. You would expect
each Car object to have a weight.

You wouldn't expect every car to weigh the same, so you wouldn't expect
each car's weight to be held in the prototype chain, shared by all cars.

You would expect each car to have it's own weight property. If you
believe in OO you would expect the weight property to be put there by
code associated with vehicles, and for the property to be put into the
car object. I.e you would expect the weight property to be inherited,
but not from another object.

John
--
John Harris