FAQ suggestion: Does JavaScript have classes and instances?
Jonathan Fine
I thought this might be a good question for the FAQ.
http://www.jibbering.com/faq/
--
Jonathan
Garrett Smith
> Hi
>
> I thought this might be a good question for the FAQ.
I think you want to propose a question about about objects instantiation.
<nitpick>
The message does not clearly indicate that, though the subject does.
http://www.jibbering.com/faq/#ask
| # Use the Subject: line to show the type of problem you have but
| include the question in the body as well.
</nitpick>
Did you see my reply to:
"Re: inheritance issue, seems to be sharing data incorrectly"
or did my response not answer that, or did you feel a new thread was
best or ?
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Richard Cornford
> Hi
>
> I thought this might be a good question for the FAQ.
Where is the question, or are you referring to the subject header of
your post?
What you are doing here appears to be asking someone else (presumably
anyone else) to devote their (free) time to writing a (more or less)
complete summery of a complex subject, sufficiently concisely for
inclusions in the FAQ. That is quite a lot to ask (and far too much to
demand) of someone else.
Existence is filled with things that one might wish were different to
the way they are. Of the things that can be changed, they are more
likely to be changed by positive action, as opposed to merely
complaining. In this context, the most positive action you could take
would be to propose a full draft text for the addition to the FAQ that
you would like to see.
Richard.
Jonathan Fine
> Jonathan Fine wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
> <snip>
>
> Where is the question, or are you referring to the subject header of
> your post?
The subject.
> What you are doing here appears to be asking someone else (presumably
> anyone else) to devote their (free) time to writing a (more or less)
> complete summery of a complex subject, sufficiently concisely for
> inclusions in the FAQ. That is quite a lot to ask (and far too much to
> demand) of someone else.
It others agree that it's a good question for the FAQ, then it's
something I'm willing to contribute to.
> Existence is filled with things that one might wish were different to
> the way they are. Of the things that can be changed, they are more
> likely to be changed by positive action, as opposed to merely
> complaining. In this context, the most positive action you could take
> would be to propose a full draft text for the addition to the FAQ that
> you would like to see.
I was not complaining. I made a positive suggestion. Richard, do you
like the idea?
--
Jonathan
Jonathan Fine
> Jonathan Fine wrote:
>> I thought this might be a good question for the FAQ.
>
> I think you want to propose a question about about objects instantiation.
[snip]
> Did you see my reply to:
> "Re: inheritance issue, seems to be sharing data incorrectly"
>
> or did my response not answer that, or did you feel a new thread was
> best or ?
Yes I did, Garrett. I'm not sure anyone else did, though. That's
probably why I started a new thread. Maybe I could have done better.
Sadly, Garrett, only one person responded to your message, and then not
to you FAQ suggestions (response below)
===
> Clone, and Crockford's beget(), have been well covered here and in
> various blogs (including Crockford's own). Clone may well be a
> suitable FAQ topic, even if the entry is just a summary with links to
> clone() and beget() threads.
>
Links seems better; explanation of the prototype chain, scope, and
inheritance techniques are too involved for the FAQ.
Maybe:
How can I clone an object?
* LRN clone method/ link to article [link]
* link to cloning using |for in| borrowing [link]
How does inheritance work?
javascript uses prototype inheritance, [link]
members can be hidden using Scope [link]
If those questions are sufficient, and the answer format is sufficient,
then pick best articles need to be picked and linked to by replacing
"[link]" with an actual link.
===
--
Jonathan
matt prokes
Here is a simplified way of doing what java would describe as
packages.
object namespaces:
v={},v.r={},v.r.t=function(){alert('hi');};
You can now do this.
v.r.t();
Though this does not create an instance of the object, it just
executes the function.
Here is a simple example of working with javascript with a concept
similar to what java would describe as a class.
t = function(x){
this.call = function(){alert(x);}
}
If you know other programming languages, for the point of this
discussion, you can think of a top level function as a class (although
function also serves other purposes, as methods, functions, etc).
So now how would we create a instance of object t?
var hi = new t('Hi');
hi.call();
(you should get an alert)
Ok, lets create another instance.
var hii = new t('Hii');
hii.call();
(you should get a new and slightly different alert)
Keep in mind this is a very simplified view of things, for certain
development groups (particularly the c/c++/java people javascript can
be very confusing because it is a implicit language instead of an
explicit language. Thus it can take years to learn for all its
beauty.)
Classes and instances are NOT the only way to work with javascript
objects, and they are not always appropriate (just as a abstract class
or inheritance in java is not always appropriate). I would suggest you
research the other ways of working with objects, in specific closures,
object literals, and functional programming.
Richard Cornford
> Richard Cornford wrote:
>> Jonathan Fine wrote:
>>> Hi
>>>
>>> I thought this might be a good question for the FAQ.
>> <snip>
>>
>> Where is the question, or are you referring to the subject
>> header of your post?
>
> The subject.
Then don't do that; you are not supposed to assume that the subject
header will be available to someone reading the message body.
>> What you are doing here appears to be asking someone else
>> (presumably anyone else) to devote their (free) time to
>> writing a (more or less) complete summery of a complex
>> subject, sufficiently concisely for inclusions in the FAQ.
>> That is quite a lot to ask (and far too much to demand)
>> of someone else.
>
> It others agree that it's a good question for the FAQ, then
> it's something I'm willing to contribute to.
You expect agreement before anyone knows what they are supposed to be
agreeing to?
>> Existence is filled with things that one might wish were
>> different to the way they are. Of the things that can be
>> changed, they are more likely to be changed by positive
>> action, as opposed to merely complaining. In this context,
>> the most positive action you could take would be to propose
>> a full draft text for the addition to the FAQ that you would
>> like to see.
>
> I was not complaining. I made a positive suggestion.
You did no more than propose that something should be different from the
way it is.
> Richard, do you like the idea?
The purpose of such a question is to provide an opportunity to get some
point, that it is considered important to convey, across to people
interested in javascript (and/or the group). Without some idea of what
that point is supposed to be there is simply nothing to judge here.
After all, the accurate answers to the question as asked are both "yes"
and "no", and neither answers are worth hearing.
Richard.
Jonathan Fine
[snip]
>> It others agree that it's a good question for the FAQ, then
>> it's something I'm willing to contribute to.
>
> You expect agreement before anyone knows what they are supposed to be
> agreeing to?
I'm asking: Do you think
Does JavaScript have classes and instances?
is a good question for the FAQ. That's all.
I'm NOT asking, do you think an answer that's not been written yet is a
good answer to this question.
Would you like to express an opinion on the question now, Richard?
--
Jonathan
Richard Cornford
> Richard Cornford wrote:
<snip>
>>> It others agree that it's a good question for the FAQ, then
>>> it's something I'm willing to contribute to.
>
>> You expect agreement before anyone knows what they are supposed
>> to be agreeing to?
>
> I'm asking: Do you think
> Does JavaScript have classes and instances?
> is a good question for the FAQ. That's all.
And I am not going to be railroaded into implicitly endorsing an
answer that I have not yet seen.
> I'm NOT asking, do you think an answer that's not been written yet
> is a good answer to this question.
You are not doing much else besides that.
> Would you like to express an opinion on the question now, Richard?
I have expressed an opinion about the question (you edited it out).
That opinion was that possible answers to the question range from "no"
to "yes" and don't necessarily include anything more useful in-
between. In that case pinning down what points the answer is should be
addressing is necessary before moving formward.
Richard.
Lasse Reichstein Nielsen
[Does JavaScript have classes and instances?]
> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/
That's an easy question: It depends on what you mean by "classes" and
"instances" :P
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Thomas 'PointedEars' Lahn
> Jonathan Fine <jf...@pytex.org> writes:
> [Does JavaScript have classes and instances?]
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> That's an easy question: It depends on what you mean by "classes" and
> "instances" :P
And "JavaScript" :)
Languages that implement ECMAScript up to Edition 3 (in the following: ES3)
do not have classes as that is (only) a prototype-based object-oriented
programming language. They do have instances, though: In the Specification,
the term "instance" is used for objects that are created with certain
constructors. For example, there are "Array instances" (section 15.4.5)
that are created, explicitly or implicitly, using the Array() constructor,
which are attributed certain non-inherited properties per that section.
AISB, if the Specification uses that term in that way, there is no good
reason that it should not be used in that way in discussions about
implementations of ECMAScript.
JavaScript™ is Netscape's/Mozilla.org's implementation of ECMAScript.
JavaScript up to version 1.8.1 (current) is only prototype-based and does
not have classes, but it has instances (as defined by the Specification).
JavaScript 2.0, which is based on an earlier Netscape proposal for
ECMAScript Edition 4 (in the following: ES4), has classes (in the sense of
class-based OOP), and it has instances both in the prototype-based and in
the class-based sense (i.e. instances of classes). JavaScript™ can be used
client-side in Netscape and Mozilla.org applications (those using Gecko),
and server-side e.g. with Netscape Enterprise Server-compatible Web servers.
No production-quality JavaScript™ version that supports classes has been
observed to date; there is only the Epimetheus test implementation of
JavaScript 2.0 (apparently development has been suspended after the AOL
takeover of Netscape).
Opera Software ASA has also created an (prototype-based) implementation of
ECMAScript Edition 3 for their browsers that they call "JavaScript" which
differs from the aforementioned JavaScript™ in several respects (most
notably, it does not support JavaScript™'s latest proprietary extensions; it
has therefore been referred to as "Opera ECMAScript" elsewhere). The same
applies to the implementation from KHTML (Konqueror HTML), KJS (Konqueror
JavaScript), and that in Apple WebKit, JavaScriptCore, which can be used in
Apple Safari and other WebKit-based products.
JScript is Microsoft's implementation of ECMAScript. JScript up to version
5.8.x (current) is only prototype-based and does not have classes; it can be
used client-side e.g. in the MSHTML component that is used e.g. in Microsoft
Internet Explorer, and server-side in the ASP framework. JScript 7.0 and
later (.NET) are implementations of ES4, and therefore support class-based
inheritance as well; they can be used server-side in the ASP .NET framework.
ActionScript is Macromedia/Adobe's implementation of ECMAScript, to be used
in Macromedia/Adobe Flash "movies". ActionScript up to version 2.0 is an
implementation of ECMAScript up to Edition 3, thus only prototype-based.
ActionScript 3.0 is an implementation of ES4 and supports class-based
inheritance as well.
There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
recently mentioned BlackBerry's implementation), and there may be other
implementations of ES4 that support class-based inheritance. However, no
implementation that supports class-based inheritance has been observed to
be supported in Web browsers to date.
The ECMAScript Support Matrix (short: ES Matrix, or just Matrix in paying
homage to the "Matrix" trilogy)¹ is an ongoing effort to catalog all
reasonably well distributed ECMAScript implementations and their features,
in order to provide an overview about which language features can be
considered safe as they are interoperable among the more common versions of
the cataloged implementations; and about which features are special to one
or more, but not all, implementations or versions, so that they need to be
used with care. Your contribution is appreciated.
Regards,
PointedEars
___________
¹ <http://PointedEars.de/es-matrix>
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
kangax
> Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>> That's an easy question: It depends on what you mean by "classes" and
>> "instances" :P
>
> And "JavaScript" :)
> Opera Software ASA has also created an (prototype-based) implementation of
> ECMAScript Edition 3 for their browsers that they call "JavaScript" which
> differs from the aforementioned JavaScript™ in several respects (most
> notably, it does not support JavaScript™'s latest proprietary extensions; it
> has therefore been referred to as "Opera ECMAScript" elsewhere). The same
Opera itself usually refers to it as their ECMAScript implementation
too. Opera also explicitly states that their ECMAScript implementation
approximately aligns with JavaScript 1.3/1.5 Core
<http://www.opera.com/docs/specs/presto22/#ecmascript>, although one can
see that their latest version (Opera 10) already goes slightly beyond
and adds some (?) of the JavaScript 1.6 features
<http://www.opera.com/docs/specs/presto22/ecmascript/index.dml>, such as
Array's extensions.
[...]
> There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
> recently mentioned BlackBerry's implementation), and there may be other
I was thinking of running sputniktests
<http://code.google.com/p/sputniktests/> - an ECMA-262 conformance test
suite, recently released by Google - to determine the coverage of ES3
support by Blackberry implementation. I just need to first extract those
somehow to be able to run them online (since automation tools that come
with the suite
<http://code.google.com/p/sputniktests/wiki/RunningSputnik> are not
quite applicable for something like a mobile device).
> implementations of ES4 that support class-based inheritance. However, no
> implementation that supports class-based inheritance has been observed to
> be supported in Web browsers to date.
Excellent overview. Thank you.
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Jonathan Fine <jf...@pytex.org> writes:
>>> [Does JavaScript have classes and instances?]
>>>> I thought this might be a good question for the FAQ.
>>>> http://www.jibbering.com/faq/
>>> That's an easy question: It depends on what you mean by "classes" and
>>> "instances" :P
>> And "JavaScript" :)
> [...]
>> Opera Software ASA has also created an (prototype-based) implementation of
>> ECMAScript Edition 3 for their browsers that they call "JavaScript" which
>> differs from the aforementioned JavaScript™ in several respects (most
>> notably, it does not support JavaScript™'s latest proprietary extensions; it
>> has therefore been referred to as "Opera ECMAScript" elsewhere). The same
>
> Opera itself usually refers to it as their ECMAScript implementation
> too. Opera also explicitly states that their ECMAScript implementation
> approximately aligns with JavaScript 1.3/1.5 Core
> <http://www.opera.com/docs/specs/presto22/#ecmascript>, although one can
> see that their latest version (Opera 10) already goes slightly beyond
> and adds some (?) of the JavaScript 1.6 features
> <http://www.opera.com/docs/specs/presto22/ecmascript/index.dml>, such as
> Array's extensions.
Yes, the implementation of the Standard includes the possibility of
additional features. The Matrix has you :)
> [...]
>
>> There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
>> recently mentioned BlackBerry's implementation), and there may be other
>
> I was thinking of running sputniktests
> <http://code.google.com/p/sputniktests/> - an ECMA-262 conformance test
> suite, recently released by Google - to determine the coverage of ES3
> support by Blackberry implementation. I just need to first extract those
> somehow to be able to run them online (since automation tools that come
> with the suite
> <http://code.google.com/p/sputniktests/wiki/RunningSputnik> are not
> quite applicable for something like a mobile device).
Somehow I doubt that Google developers have the necessary background to
write such a piece of software. Just look at the junk that they wrote
before and dared to call it source code.
BTW, the next release of the ES Matrix will include feature tests. I am
using them already in the local version to fill in the missing parts more
efficiently.
>> implementations of ES4 that support class-based inheritance. However, no
>> implementation that supports class-based inheritance has been observed to
>> be supported in Web browsers to date.
>
> Excellent overview. Thank you.
You are welcome.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jonathan Fine
Here's my first attempt to answer my self-imposed question:
Does JavaScript have classes and instances?
<answer>
In many languages, each object belongs to and inherits properties from a
class. Each class, in turn can inherit properties from one (or in some
languages multiple) other classes. JavaScript provides something like
this, but does it differently.
In JavaScript the objects (except the null object) form a tree, whose
root is Object.prototype. Each object inherits properties from its
ancestors, all the way up to the root of the tree.
</answer>
((At this point I am a bit stuck. I'd like to say that 'new' adds
objects to the tree, and the use of the 'instanceof' operator. But
they're a bit complex to explain. Neither are mentioned in the current FAQ.
But 'new' is not as bad as all that, provided we don't try to explain
everything, and instanceof can be left until later.))
<answer>
If Fn is a function that returns undefined and Fn.prototype is a
non-null object 'x' then
y = new Fn(...);
creates an object 'y' whose parent is 'x'. In this way we can add to
the tree of objects.
If we wish to, we can think of 'Fn' as a class and 'y' as an instance of
this class, just as we can think of a pair [2, 3] (or triple [2, 3, 4])
as a point.
</answer>
((We've now ready to answer the question. We've told the reader about
the inheritance tree and the new operator.)
<answer>
JavaScript does not have a built-in concept of class. It has an
inheritance tree and the 'new' operator, which adds nodes to the tree.
</answer>
((At this point, providing class behaviours in JavaScript could be
discussed.))
And now I'm out of time.
--
Jonathan
Dr J R Stockton
dn...@giganews.com>, Thu, 30 Jul 2009 00:25:42, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:
>Jonathan Fine wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
><snip>
>
>Where is the question, or are you referring to the subject header of
>your post?
>
>What you are doing here appears to be asking someone else (presumably
>anyone else) to devote their (free) time to writing a (more or less)
>complete summery of a complex subject, sufficiently concisely for
>inclusions in the FAQ. That is quite a lot to ask (and far too much to
>demand) of someone else.
You are being grossly unreasonable.
>Existence is filled with things that one might wish were different to
>the way they are. Of the things that can be changed, they are more
>likely to be changed by positive action, as opposed to merely
>complaining.
I see no complaint there; the OP gave a straightforward question.
> In this context, the most positive action you could take would be to
>propose a full draft text for the addition to the FAQ that you would
>like to see.
Those who are most likely to perceive a possible or apparent need for a
FAQ section are, or certainly rightly include, those who are least
likely to be able to provide a helpful draft.
However, ISTM that such a section would only he helpful to the
unenterprising or ill-prepared. The FAQ cites the language standards,
freely available in PDF; and searching those for substrings "class" and
"instance" quickly indicates the answer in each case.
A better Subject might be "Does JavaScript have anything like classes
and instances?" though it would be necessary in the answer to indicate
what was to be taken as definitive for class & instance.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html>
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
RobG
> Hi
>
> Here's my first attempt to answer my self-imposed question:
> Does JavaScript have classes and instances?
I think Thomas has answered that fairly thoroughly already.
> <answer>
> In many languages, each object belongs to and inherits properties from a
> class. Each class, in turn can inherit properties from one (or in some
> languages multiple) other classes.
I don't think it is necessary to summarise class inheritance,
particularly when javascript (in general) doesn't have classes. I
think the question you are trying to answer is: how does javascript
implement inhertiance?
That *is* a topic worth of the FAQ, though questions are more likely
to focus on "what is a prototype" or "how do I use Foo.prototype" or
similar.
> JavaScript provides something like
> this, but does it differently.
>
> In JavaScript the objects (except the null object) form a tree, whose
> root is Object.prototype. Each object inherits properties from its
> ancestors, all the way up to the root of the tree.
Objects inherit from their constructor's public prototype, not from
their "ancestors".
<FAQENTRY>
The article on closures could be split into two: one relating to
"dentifier Resolution, Execution Contexts and Scope Chains", and the
other on closures. Or an extra entry could be provided in the index
to the early sections, I find that part of the closures article stands
on its own as a great introduction to some important javascript
fundamentals.
A section on prototype inheritance would compliment that article (or
artciles if split into two).
</FAQENTRY>
--
Rob
Malcolm Dew-Jones
: Hi
: Here's my first attempt to answer my self-imposed question:
: Does JavaScript have classes and instances?
The term "class" is not a language element, but it is an important unit of
analysis of a system at runtime.
In Javascript, for any set of "behaviours" being considered, the set of
objects that currently have those behaviours are in the same class. Each
of those objects can be considered an instance of the class.
The most rigid interpretation is when the "behaviours" must be all the
behaviours of the object, but it is more useful to only require that an
object has _at least_ the "behaviours" in question.
"Behaviours" is not meant to be well defined, it does not have to be
methods, or property names. Those would most commonly be the basis of how
you wish to compare the "class-ish-ness" of objects, but anything relevant
to your analysis of the runtime system could be considered a "behavior"
that would be the basis of interpreting some objects as being in the same
class.
To sum up, Javascript has a dynamic, non-formal but useful interpretation
of "class".
$0.01
kangax
>> In JavaScript the objects (except the null object) form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> Objects inherit from their constructor's public prototype, not from
> their "ancestors".
Wouldn't it be more precise to say that objects "inherit" dynamically
from whatever their internal prototype property (aka [[Prototype]])
references? constructor's public prototype just happens to act as a
starting point for that internal property when object is instantiated.
This "difference" can be easily observed when object keeps its original
inheritance relationship after reassignment of constructor's public
prototype property:
function F(){};
F.prototype.x = 1;
var obj = new F();
// reassign `prototype`
obj.constructor.prototype = { x: 2 };
obj.x; // 1
[...]
--
kangax
Lasse Reichstein Nielsen
> Here's my first attempt to answer my self-imposed question:
> Does JavaScript have classes and instances?
>
>
> <answer>
> In many languages, each object belongs to and inherits properties from
> a class. Each class, in turn can inherit properties from one (or in
> some languages multiple) other classes. JavaScript provides something
> like this, but does it differently.
Very vague. "Many languages", "something like this", "differently".
It doesn't define what a class is, except that "objects" inherit
"properties" from it, and "classes" also inherit properties from
other classes, so you can't easily tell what the difference between
an object and a class is.
Rather than reinventing the wheel, refer to some external definition
of "class based language", "class based OO" or "class based
inheritance", e.g., http://en.wikipedia.org/wiki/Class-based_programming
and try to get a good grasp of the concepts before writing about them.
Or just refer to one (or preferably more) of the existing pages that
discuss the topice, e.g.
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Class-Based_vs._Prototype-Based_Languages
> In JavaScript the objects (except the null object)
Except "null" is not an object (even though "typeof null == 'object'").
> form a tree, whose
> root is Object.prototype. Each object inherits properties from its
> ancestors, all the way up to the root of the tree.
This is technically correct, but doesn't say anything about classes
or instances. It's about inheritance instead.
> </answer>
>
> ((At this point I am a bit stuck. I'd like to say that 'new' adds
> objects to the tree, and the use of the 'instanceof' operator. But
> they're a bit complex to explain. Neither are mentioned in the
> current FAQ.
"new" creats objects. You already said that all objects are in the
tree, so no need to say that the created objects are added.
You can't explain "instanceof" without describing the relation between
"new" and a function's "prototype" property. At this point you are
describing a significant part of the Javascript language as background
for giving an answer that is most likely just going to be "so no,
Javascript doesn't have classes".
> But 'new' is not as bad as all that, provided we don't try to explain
> everything, and instanceof can be left until later.))
>
> <answer>
> If Fn is a function that returns undefined
Doesn't have to return "undefined". As long as it doesn't return another
object than "this", it will work as a constructor.
> and Fn.prototype is a
> non-null object 'x' then
> y = new Fn(...);
> creates an object 'y' whose parent is 'x'.
"whose internal prototype is"
> In this way we can add to
> the tree of objects.
The "tree of objects" concept is overkill for this explanation.
It adds another concept, on top of what we already have, that just confuzes
the explanation.
> If we wish to, we can think of 'Fn' as a class and 'y' as an instance
> of this class, just as we can think of a pair [2, 3] (or triple [2, 3,
> 4]) as a point.
"can think of" is not the same as "is". The conclusion from all this
would be that "no, javascript doesn't have classes".
The point example just confuses things by adding more concepts again.
We can think of, or imagine, anything. That's not an argument for
anything, except that it really isn't what we choose to think of it
as.
> </answer>
>
> ((We've now ready to answer the question. We've told the reader about
> the inheritance tree and the new operator.)
>
> <answer>
> JavaScript does not have a built-in concept of class. It has an
> inheritance tree and the 'new' operator, which adds nodes to the tree.
Drop the "tree" concept.
When writing for the web, start with the conclusion and then elaborate,
instead of starting with a lot of built-up before getting to the point
(I know how hard that is - building up is my preferred way of
explaining too).
A much shorter version:
"Javascript does not have a built-in concept of class. When a new object
is created, it inherits properties directly from another object (it's
"prototype").
New objects are created by the syntax "new func(args)". This creates a
new object which inherits from the object "func.prototype", and
initializes it by calling "func(args)" with "this" referring to the
new object.
The internal prototype link of an object is exposed in some
implementations as a property called "__proto__". This is not required
by the specification.
RobG
> RobG wrote:
> > On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
> [...]
> >> In JavaScript the objects (except the null object) form a tree, whose
> >> root is Object.prototype. Each object inherits properties from its
> >> ancestors, all the way up to the root of the tree.
>
> > Objects inherit from their constructor's public prototype, not from
> > their "ancestors".
>
> Wouldn't it be more precise to say that objects "inherit" dynamically
> from whatever their internal prototype property (aka [[Prototype]])
> references? constructor's public prototype just happens to act as a
> starting point for that internal property when object is instantiated.
Yes, of course, there's a lot more missing. A full and detailed
description is required, we are only nibbling at the edges here. I
wrote an article some time ago to describe prototype inheritance, it
was much longer than I expected it to be and didn't cover all aspects.
I may review it and perhaps post a link, it will take a few days to
get around to that. Perhaps you have written something on your blog? I
can't tell as I can't access it from the site I'm currently at, it's
blocked due to be being categorised as "Social Networking and Personal
Sites".
--
Rob
Jonathan Fine
> On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
>> Hi
>>
>> Here's my first attempt to answer my self-imposed question:
>> Does JavaScript have classes and instances?
>
> I think Thomas has answered that fairly thoroughly already.
>
>
>> <answer>
>> In many languages, each object belongs to and inherits properties from a
>> class. Each class, in turn can inherit properties from one (or in some
>> languages multiple) other classes.
>
> I don't think it is necessary to summarise class inheritance,
> particularly when javascript (in general) doesn't have classes. I
> think the question you are trying to answer is: how does javascript
> implement inhertiance?
I agree that it is not necessary, but it may be helpful. I was
intending finish the Answer by referring to 'implementations of Classes'
in JavaScript.
> That *is* a topic worth of the FAQ, though questions are more likely
> to focus on "what is a prototype" or "how do I use Foo.prototype" or
> similar.
I'm glad we agree here. I think "How do I use Foo.prototype" could be a
good question, but to lead up I think we need "Does JavaScript have
classes and instances">
>> JavaScript provides something like
>> this, but does it differently.
>>
>> In JavaScript the objects (except the null object) form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> Objects inherit from their constructor's public prototype, not from
> their "ancestors".
I read statements like this many times, when I was learning JavaScript.
They were, for me, unhelpful. I wanted a simple, exact and true
statement that I could hold on to. This statement is insufficiently
exact to be true.
It does not tell me what happens when I replace Fn.prototype by another
object, or when Fn itself ceases to exist. Without that, I cannot
understand the construction variously called begat, clone and create.
> <FAQENTRY>
> The article on closures could be split into two: one relating to
> "dentifier Resolution, Execution Contexts and Scope Chains", and the
> other on closures. Or an extra entry could be provided in the index
> to the early sections, I find that part of the closures article stands
> on its own as a great introduction to some important javascript
> fundamentals.
>
> A section on prototype inheritance would compliment that article (or
> artciles if split into two).
> </FAQENTRY>
I think this might best be discussed in another thread.
--
Jonathan
Jonathan Fine
> Jonathan Fine (jf...@pytex.org) wrote:
> : Hi
>
> : Here's my first attempt to answer my self-imposed question:
> : Does JavaScript have classes and instances?
>
> The term "class" is not a language element, but it is an important unit of
> analysis of a system at runtime.
I like this sentence a great deal. Perhaps better is "..., but may help
when understanding JavaScript code."
This, by itself, answers the question: "Does JavaScript have classes?"
> In Javascript, for any set of "behaviours" being considered, the set of
> objects that currently have those behaviours are in the same class. Each
> of those objects can be considered an instance of the class.
>
> The most rigid interpretation is when the "behaviours" must be all the
> behaviours of the object, but it is more useful to only require that an
> object has _at least_ the "behaviours" in question.
>
> "Behaviours" is not meant to be well defined, it does not have to be
> methods, or property names. Those would most commonly be the basis of how
> you wish to compare the "class-ish-ness" of objects, but anything relevant
> to your analysis of the runtime system could be considered a "behavior"
> that would be the basis of interpreting some objects as being in the same
> class.
I think a discussion of prototype inheritance is required here.
> To sum up, Javascript has a dynamic, non-formal but useful interpretation
> of "class".
I really like this sentence also.
>
> $0.01
Thank you for this, Malcolm. I like what you've written.
--
Jonathan
Jonathan Fine
Wonderfully put. Thank you, kangax. This is why I prefer to start with
the inheritance tree, and then explain 'new' in terms of the tree.
--
Jonathan
Jonathan Fine
<snip>
> A much shorter version:
>
> "Javascript does not have a built-in concept of class. When a new object
> is created, it inherits properties directly from another object (it's
> "prototype").
>
> New objects are created by the syntax "new func(args)". This creates a
> new object which inherits from the object "func.prototype", and
> initializes it by calling "func(args)" with "this" referring to the
> new object.
>
> The internal prototype link of an object is exposed in some
> implementations as a property called "__proto__". This is not required
> by the specification.
There's a lot I like about this. However, perhaps it's necessary to say
what inheritance is.
--
Jonathan
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
[snip]
>> In JavaScript the objects (except the null object)
>
> Except "null" is not an object (even though "typeof null == 'object'").
I think there's a problem with the FAQ. It contianss 'undefined' twice
and 'null' once, and then only in passing. I think we need a question:
What's the difference between undefined and null?
>> form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> This is technically correct, but doesn't say anything about classes
> or instances. It's about inheritance instead.
In some other languages, classes and instances are the way to provide
inheritance. That's why I think it's relevant.
>> </answer>
>>
>> ((At this point I am a bit stuck. I'd like to say that 'new' adds
>> objects to the tree, and the use of the 'instanceof' operator. But
>> they're a bit complex to explain. Neither are mentioned in the
>> current FAQ.
>
> "new" creats objects. You already said that all objects are in the
> tree, so no need to say that the created objects are added.
>
> You can't explain "instanceof" without describing the relation between
> "new" and a function's "prototype" property. At this point you are
> describing a significant part of the Javascript language as background
> for giving an answer that is most likely just going to be "so no,
> Javascript doesn't have classes".
I'm inclined to agree. I don't think 'instanceof' is core to the FAQ.
>> But 'new' is not as bad as all that, provided we don't try to explain
>> everything, and instanceof can be left until later.))
>>
>> <answer>
>> If Fn is a function that returns undefined
>
> Doesn't have to return "undefined". As long as it doesn't return another
> object than "this", it will work as a constructor.
Yes, I knew that when I wrote it. But I did not want to complicate
matters. I rarely see a function used as a constructor returning other
than undefined.
And what about this (not tested):
var store = {}
var Fn = function(locn){
store.push(this);
return store;
};
new Fn(); new Fn(); new Fn();
This (admittedly obscure) use of new is not covered by the text you propose.
>> and Fn.prototype is a non-null object 'x' then
>> y = new Fn(...);
>> creates an object 'y' whose parent is 'x'.
>
> "whose internal prototype is"
That's fine, provided we have the concept of 'internal prototype'.
>> In this way we can add to the tree of objects.
>
> The "tree of objects" concept is overkill for this explanation.
> It adds another concept, on top of what we already have, that just confuzes
> the explanation.
Most JavaScript programmers are already aware of the DOM tree. The tree
of objects is the concept that has allowed me to understand JavaScript
inheritance.
[snip]
> Drop the "tree" concept.
> When writing for the web, start with the conclusion and then elaborate,
> instead of starting with a lot of built-up before getting to the point
> (I know how hard that is - building up is my preferred way of
> explaining too).
I think the tree concept is the main area where we don't agree.
> A much shorter version:
[snip]
I've put my comments on this in another post.
Thank you, Lasse, for your contribution.
--
Jonathan
Jonathan Fine
[snip]
>> In this context, the most positive action you could take would be to
>> propose a full draft text for the addition to the FAQ that you would
>> like to see.
>
> Those who are most likely to perceive a possible or apparent need for a
> FAQ section are, or certainly rightly include, those who are least
> likely to be able to provide a helpful draft.
This is a very good point.
> However, ISTM that such a section would only he helpful to the
> unenterprising or ill-prepared. The FAQ cites the language standards,
> freely available in PDF; and searching those for substrings "class" and
> "instance" quickly indicates the answer in each case.
I've just taken a look at 4.2.1 Objects. It does not tell us that we
can write:
var Fn = function(){ ... }
var x = new Fn();
Moreover, I've not found in it helpful regarding 'instance'.
So I'd say a link to the FAQ is not sufficiently helpful.
> A better Subject might be "Does JavaScript have anything like classes
> and instances?" though it would be necessary in the answer to indicate
> what was to be taken as definitive for class & instance.
I don't see that adding "anything like" helps, unless we've already said
that JS does not have classes and instances.
--
Jonathan
kangax
> On Jul 31, 1:43 pm, kangax <kan...@gmail.com> wrote:
>> RobG wrote:
>>> On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
>> [...]
>>>> In JavaScript the objects (except the null object) form a tree, whose
>>>> root is Object.prototype. Each object inherits properties from its
>>>> ancestors, all the way up to the root of the tree.
>>> Objects inherit from their constructor's public prototype, not from
>>> their "ancestors".
>> Wouldn't it be more precise to say that objects "inherit" dynamically
>> from whatever their internal prototype property (aka [[Prototype]])
>> references? constructor's public prototype just happens to act as a
>> starting point for that internal property when object is instantiated.
>
> Yes, of course, there's a lot more missing. A full and detailed
> description is required, we are only nibbling at the edges here. I
> wrote an article some time ago to describe prototype inheritance, it
> was much longer than I expected it to be and didn't cover all aspects.
>
> I may review it and perhaps post a link, it will take a few days to
> get around to that. Perhaps you have written something on your blog? I
I haven't, but there is an article by Joost
<http://joost.zeekat.nl/constructors-considered-mildly-confusing.html>.
I remember reading it a couple of years ago, when I was just starting
with Javascript and tried to understand its inheritance.
I think I was still confused after reading that piece though and it was
Richard's and Lasse's posts in the archives (and my own constant
experiments) that made things more or less clear.
> can't tell as I can't access it from the site I'm currently at, it's
> blocked due to be being categorised as "Social Networking and Personal
> Sites".
I wonder what that categorization is based on.
--
kangax
John G Harris
>Hi
>
>I thought this might be a good question for the FAQ.
Question:
Does JavaScript have classes and instances?
Answer:
Yes it does, Jim, but not as we in C++/Java know it.
In more detail and using posh words :
C++, Java, etc have declarative class definitions, whereas javascript
has imperative class definitions.
That is, in C++, Java, etc you tell the compiler what data fields you
want in each object and what functions (methods) you want the object to
have access to. The compiler has the job of writing the code that
allocates space in storage for the data fields, with padding as
necessary to ensure integers start on 4 byte boundaries, etc. It also
has the job of writing the code that enables the object's functions to
access the right object's data.
But in javascript all the compiler/translator does is to give you a raw
object. You write the code that provides data fields and access to
functions, and you write the code that enables the object's functions to
access the right object's data (with a little help from the language).
Even worse, javascript provides several different ways of doing this.
For each way there is someone ready to jump up and down and scream that
this way is the only right way.
Some people claim that 'class' is restricted to declarative class
definitions, but this is muddled thinking. A class of Date objects is
just as much a class of objects in javascript as it is in Java. That
said, it is important to remember that there are significant differences
between javascript and the other kind of languages.
John
--
John Harris
Jonathan Fine
[snip]
> [...] there is an article by Joost
> <http://joost.zeekat.nl/constructors-considered-mildly-confusing.html>.
> I remember reading it a couple of years ago, when I was just starting
> with Javascript and tried to understand its inheritance.
>
> I think I was still confused after reading that piece though and it was
> Richard's and Lasse's posts in the archives (and my own constant
> experiments) that made things more or less clear.
I've read that article, and recommend it to all who have contributed to
this thread.
Like kanjax, I only learnt what was really going on by writing code,
observing its behaviour and understanding what I saw. I think some
experiments of this sort should appear in, or be linked to, the FAQ.
--
Jonathan
Jonathan Fine
> On Wed, 29 Jul 2009 at 22:36:43, in comp.lang.javascript, Jonathan Fine
> wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> Question:
>
> Does JavaScript have classes and instances?
>
>
> Answer:
>
> Yes it does, Jim, but not as we in C++/Java know it.
>
> In more detail and using posh words :
>
> C++, Java, etc have declarative class definitions, whereas javascript
> has imperative class definitions.
I have to think about what this means. The way I'd like to read it is
that for C++/Java there is a primitive concept of class, accessed
through a class declaration statement, whereas in JavaScript you get to
make your own concept of class. I'm not the FAQ reader would have the
time and patience to rise to such a level of abstraction.
> That is, in C++, Java, etc you tell the compiler what data fields you
> want in each object and what functions (methods) you want the object to
> have access to. The compiler has the job of writing the code that
> allocates space in storage for the data fields, with padding as
> necessary to ensure integers start on 4 byte boundaries, etc. It also
> has the job of writing the code that enables the object's functions to
> access the right object's data.
I use Python, and unless you optimize by using __slots__ the compiler
does not allocate storage space for data fields. All the same, I'd
group Python with C++ and Java here.
http://docs.python.org/reference/datamodel.html#slots
> But in javascript all the compiler/translator does is to give you a raw
> object. You write the code that provides data fields and access to
> functions, and you write the code that enables the object's functions to
> access the right object's data (with a little help from the language).
And again in Python you write the code that gives you the data fields.
I think, John, you've identified an important difference between
C++/Java vs. JavaScript. But not, I think, the basic difference
regarding classes.
JavaScript has no built-in concept of class. It does have inheritance
between objects, and this allows you to build your own concept of class.
> Even worse, javascript provides several different ways of doing this.
> For each way there is someone ready to jump up and down and scream that
> this way is the only right way.
Well, this may be true. But I don't think it can be said in this way in
the FAQ (smile).
> Some people claim that 'class' is restricted to declarative class
> definitions, but this is muddled thinking. A class of Date objects is
> just as much a class of objects in javascript as it is in Java. That
> said, it is important to remember that there are significant differences
> between javascript and the other kind of languages.
I agree. Thank you, John, for your contributions.
--
Jonathan
Dr J R Stockton
view.co.uk>, Fri, 31 Jul 2009 12:27:57, Jonathan Fine <jf...@pytex.org>
posted:
A member of the intended class of readership may have, from experience
with a single language, a very definite idea of exactly what classes and
instances are. That idea may not exactly match the accepted generic
meanings of those terms. Therefore a simple answer, which is all that
the original Subject asks for, may be misleading or unhelpful.
The extended Subject accommodates that, and also encourages a more
positive answer as in the first sentence of 16262 4.2.1.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Jonathan Fine
> In comp.lang.javascript message <--2dnX_2AOGgSO_XnZ2dnUVZ8rudnZ2d@bright
> view.co.uk>, Fri, 31 Jul 2009 12:27:57, Jonathan Fine <jf...@pytex.org>
> posted:
>> Dr J R Stockton wrote:
>
>>> A better Subject might be "Does JavaScript have anything like classes
>>> and instances?" though it would be necessary in the answer to indicate
>>> what was to be taken as definitive for class & instance.
>> I don't see that adding "anything like" helps, unless we've already
>> said that JS does not have classes and instances.
>
>
> A member of the intended class of readership may have, from experience
> with a single language, a very definite idea of exactly what classes and
> instances are. That idea may not exactly match the accepted generic
> meanings of those terms.
Yes, I agree. This is possible. They'll be quite a few people like that.
> Therefore a simple answer, which is all that
> the original Subject asks for, may be misleading or unhelpful.
For me, the most important thing in what you say here is that the reader
may have clear and strongly held views about what classes and instances
are.
The answer will be more effective if it tells the user that these views
don't hold for JavaScript, and if appropriate encourages the user to
learn and understand what really happens in JavaScript.
> The extended Subject accommodates that, and also encourages a more
> positive answer as in the first sentence of 16262 4.2.1.
As I recall from yesterday, I thought that first sentence was fairly
good. It's a real shame that the ECMA standard is not available as
HTML. Then we'd be able to link to it.
--
Jonathan
Jorge
> (...)
> In JavaScript the objects form a tree, whose
> root is Object.prototype. Each object inherits properties from its
> ancestors, all the way up to the root of the tree.
This pictures it *perfectly*. I like it.
Just find a way to explain too that the internal [[prototype]]
attribute is what connects the leaves, that it's invisible, and that
once set it's inmutable : a subtle but important thing to note, imo.
--
Jorge.
Malcolm Dew-Jones
: Hi
: I thought this might be a good question for the FAQ.
: http://www.jibbering.com/faq/
Replacing my own $0.01's worth, and certainly not intended as a complete
answer...
Javascript is very much an object oriented language, but neither the
language nor the interpreter have any feature called a "class". To people
familiar with languages like Java or C++ that might seem contradictory.
However, as in any OOP language, the concepts of class, and instances
within a class, are still very important, and Javascript applications
certainly do use classes of objects, and the individual objects are
instances of the class(es) to which they belong.
The difference is that Javascript is a very dynamic language - its objects
simply do not require any formal predefined "thing" that you might call a
class. Instead, Javascript objects, within the runtime environment of the
Javascript interpreter, interact with each other in a well defined manner
that implements the class behaviours expected of any object oriented
language.
Jonathan Fine
Jonathan Fine wrote:
> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/
There's been a lot of really good and thoughtful response to this, and
almost every one contains something positive and useful. I think it's
time now to move to summarizing and writing up.
I think we need both, to get the best result. Summarizing is a matter
of gathering everything useful and putting it in one (or a just a few)
posts. Everyone who participated should agree with the summary, because
it's a matter of reporting: Malcolm say .... etc. The summary should
also contain the text of the drafts that have been put forward.
Writing up is much harder, and will produce text that could usefully be
added to the FAQ. A massive knowledge of JavaScript is not required,
although a proper understanding of classes and inheritance is. What is
required are writing skills and an absence of bias, being open to all
the good things that have been said.
I'm going to be very busy for the next 10 days, and so won't have time
until after then. I'd be really grateful if some volunteers took this
forward over the next week. Don't be shy - it's a really great way to
learn.
Anyone who's got the right skills and attitude could do this, even if
they've not yet contributed to this thread.
--
Jonathan
Thomas 'PointedEars' Lahn
> http://www.jibbering.com/faq/
>
> Replacing my own $0.01's worth, and certainly not intended as a complete
> answer...
Please don't. There are enough misinformation and misconceptions out of
(mis)interpretation of terms already.
> Javascript is very much an object oriented language, but neither the
> language nor the interpreter have any feature called a "class".
As for the interpreter, it remains to be seen a) what is meant by this and
b) if it has a feature called a class.
> To people familiar with languages like Java or C++ that might seem
> contradictory. However, as in any OOP language, the concepts of class,
> and instances within a class, are still very important, and Javascript
> applications certainly do use classes of objects, and the individual
> objects are instances of the class(es) to which they belong.
Rubbish.
> The difference is that Javascript is a very dynamic language - its
> objects simply do not require any formal predefined "thing" that you
> might call a class. Instead, Javascript objects, within the runtime
> environment of the Javascript interpreter, interact with each other in a
> well defined manner that implements the class behaviours expected of any
> object oriented language.
Rubbish. You have never set up a custom prototype chain or heard of
Function.prototype.call(), have you?
PointedEars
Jonathan Fine
> Please don't. There are enough misinformation and misconceptions out of
> (mis)interpretation of terms already.
> As for the interpreter, it remains to be seen a) what is meant by this and
> b) if it has a feature called a class.
> Rubbish.
> Rubbish. You have never set up a custom prototype chain or heard of
> Function.prototype.call(), have you?
Please suggest something better.
--
Jonathan
Lasse Reichstein Nielsen
[Does JavaScript have classes and instances?]
> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/
Is it frequently asked? :)
How about just:
A: No, Javascript has no language support for traditional class based
programming. A programmer can, and often do, create objects and treat
them as being from the same "class", but this only works as long as
everybody stays with the abstraction. There is no language support to
enforce the class relations.
Thomas 'PointedEars' Lahn
> Jonathan Fine <jf...@pytex.org> writes:
> [Does JavaScript have classes and instances?]
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> Is it frequently asked? :)
>
> How about just:
>
> A: No, Javascript has no language support for traditional class based
> programming. A programmer can, and often do, create objects and treat
> them as being from the same "class", but this only works as long as
> everybody stays with the abstraction. There is no language support to
> enforce the class relations.
AISB, that is wrong (if "Javascript" is understood, as you do, as a
collection of ECMAScript implementations that include JScript).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jonathan Fine
> Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>> Is it frequently asked? :)
>>
>> How about just:
>>
>> A: No, Javascript has no language support for traditional class based
>> programming. A programmer can, and often do, create objects and treat
>> them as being from the same "class", but this only works as long as
>> everybody stays with the abstraction. There is no language support to
>> enforce the class relations.
>
> AISB, that is wrong (if "Javascript" is understood, as you do, as a
> collection of ECMAScript implementations that include JScript).
I'm not sure I knew that already. Thank you, Thomas. Here's a URL.
http://msdn.microsoft.com/en-us/library/7y3sea6h(VS.80).aspx
In the FAQ I read:
===
2.2 What is JScript?
JScript is Microsoft's implementation of ECMAScript.
Questions that are specific to Microsoft's JScript may also be
appropriately asked at: microsoft.public.scripting.jscript.
===
Perhaps something could be added to 2.2 that allows us to ignore the
JScript extensions in the rest of the FAQ.
--
Jonathan
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Jonathan Fine <jf...@pytex.org> writes:
>>> [Does JavaScript have classes and instances?]
>>>> I thought this might be a good question for the FAQ.
>>>> http://www.jibbering.com/faq/
>>> Is it frequently asked? :)
>>>
>>> How about just:
>>>
>>> A: No, Javascript has no language support for traditional class based
>>> programming. A programmer can, and often do, create objects and treat
>>> them as being from the same "class", but this only works as long as
>>> everybody stays with the abstraction. There is no language support to
>>> enforce the class relations.
>> AISB, that is wrong (if "Javascript" is understood, as you do, as a
>> collection of ECMAScript implementations that include JScript).
>
> I'm not sure I knew that already.
How surprising. I told you several times before.
> Thank you, Thomas. Here's a URL.
You must be very proud of yourself now.
> [...]
> In the FAQ I read:
> ===
> 2.2 What is JScript?
>
> JScript is Microsoft's implementation of ECMAScript.
>
> Questions that are specific to Microsoft's JScript may also be
> appropriately asked at: microsoft.public.scripting.jscript.
> ===
>
> Perhaps something could be added to 2.2 that allows us to ignore the
> JScript extensions in the rest of the FAQ.
Sounds much like security by obscurity, a concept no documentation and
certainly no FAQ should be based upon. JScript .NET exists and has
practical applications. It is complete utter nonsense to attempt
to conceal its existence or ignore it in the FAQ.
Jonathan Fine
> Jonathan Fine wrote:
[snip]
>> In the FAQ I read:
>> ===
>> 2.2 What is JScript?
>>
>> JScript is Microsoft's implementation of ECMAScript.
>>
>> Questions that are specific to Microsoft's JScript may also be
>> appropriately asked at: microsoft.public.scripting.jscript.
>> ===
>>
>> Perhaps something could be added to 2.2 that allows us to ignore the
>> JScript extensions in the rest of the FAQ.
>
> Sounds much like security by obscurity, a concept no documentation and
> certainly no FAQ should be based upon. JScript .NET exists and has
> practical applications.
JScript has a 'class' extension, which is a language built-in (linked to
the 'class' reserved word that JavaScript has but does not use). It has
other extensions also.
I think it better not to describe these extensions in the FAQ (although
I'm not opposed to a JScript appendix, if useful).
I'm suggesting adding a statement such as:
===
JScript has features not in the ECMA standard. Some of the statements
in the FAQ require qualification when applied to JScript.
===
> It is complete utter nonsense to attempt
> to conceal its existence or ignore it in the FAQ.
I agree (although I'd use different words). Fortunately, no-one on this
thread is suggesting that.
--
Jonathan
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jonathan Fine wrote:
>>> In the FAQ I read:
>>> ===
>>> 2.2 What is JScript?
>>>
>>> JScript is Microsoft's implementation of ECMAScript.
>>>
>>> Questions that are specific to Microsoft's JScript may also be
>>> appropriately asked at: microsoft.public.scripting.jscript.
>>> ===
>>>
>>> Perhaps something could be added to 2.2 that allows us to ignore the
>>> JScript extensions in the rest of the FAQ.
>> Sounds much like security by obscurity, a concept no documentation and
>> certainly no FAQ should be based upon. JScript .NET exists and has
>> practical applications.
>
> JScript has a 'class' extension, which is a language built-in (linked to
> the 'class' reserved word that JavaScript has but does not use). It has
> other extensions also.
It does not have a "'class' extension". AISB: JScript (up to 5.8,
currently) and JScript .NET (7.0+) and different versions of the same
language; the former is an implementation of ECMAScript Edition 3. The
latter is an implementation of a Netscape proposal for ECMAScript Edition 4,
based on work of Waldemar Horwat (now at Google) for Netscape JavaScript 2.0
(which was never released except for the Epimetheus test implementation); as
such, it supports class-based inheritance with the `class' keyword, strict
typing and other features, which the former does not.
> I think it better not to describe these extensions in the FAQ (although
> I'm not opposed to a JScript appendix, if useful).
You have yet to provide a valid reason for why not. That said, given the
rate of misconceptions per hour that you continue to demonstrate despite
considerable, readily available documentation and thorough explanations to
the contrary, it is not likely that anyone would take any of your
suggestions for modifying the FAQ seriously.
> I'm suggesting adding a statement such as:
> ===
> JScript has features not in the ECMA standard. Some of the statements
> in the FAQ require qualification when applied to JScript.
> ===
Considered and rejected. The same could be said about any other ECMAScript
implementation, most notably JavaScript. Please do not talk about things
that you do not (yet) understand. There is enough noise from wannabes about
the topic already, and this newsgroup really does not need another VK.
Thanks in advance.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Please don't. There are enough misinformation and misconceptions out of
>> (mis)interpretation of terms already.
>>
>> As for the interpreter, it remains to be seen a) what is meant by this and
>> b) if it has a feature called a class.
>>
>> Rubbish.
>>
>> Rubbish. You have never set up a custom prototype chain or heard o
>
> Please suggest something better.
BTDT. Please learn to read or go away.
Jonathan Fine
[snip]
>> I'm suggesting adding a statement such as:
>> ===
>> JScript has features not in the ECMA standard. Some of the statements
>> in the FAQ require qualification when applied to JScript.
>> ===
>
> Considered and rejected.
I think what you mean here is that you're against it.
> The same could be said about any other ECMAScript
> implementation, most notably JavaScript.
That's a good point. I've got the impression that JavaScript is much
closer to the ECMA standard than JScript. What do you think, Thomas?
BTW, "2.1 What is ECMAScript?" in the FAQ tells us that JavaScript and
JScript may differ in host objects (such as 'document'). But I didn't
find anything here that tells me that there are major changes in the
language itself (such as the behaviour associated with reserved words
such as 'class').
> Please do not talk about things that you do not (yet) understand.
I find that by talking about things I don't understand, particularly
with those who know more and enjoy sharing their knowledge, is a very
good way to learn and understand.
So I'm sorry, Thomas, but I won't follow your advice here.
[snip]
--
Jonathan
Jorge
wrote:
>
> Considered and rejected.
That's Lahn arrogating himself the powers.
> (...) Please do not talk about things
> that you do not (yet) understand.
There's no evidence of that in what he's said so far.
And how do you dare to say so when you don't refrain from screwing it
up with closures at each and every occasion ?
("despite the fact that you do not (yet !) understand them ?")
> There is enough noise from wannabes about
> the topic already, and this newsgroup really does not need another VK.
Your chronic insufferable rudeness is (not really) amusing.
--
Jorge
Jonathan Fine
Jorge wrote (of Thomas):
> On Aug 1, 5:23 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> Your chronic insufferable rudeness is (not really) amusing.
The FAQ says (http://www.jibbering.com/faq/#posting):
Avoid being unnecessarily rude,
but do not complain about other rude posts.
Generally, I ignore off-topic content in posts to this newsgroup.
Similarly, I usually ignore content I consider to be rude.
If a post contains a mixture rude and on-topic content, I try to ignore
the material I find to be rude, and respond positively to the on-topic
content (even if I don't agree with it).
I think (or at least hope) that following the advice in the FAQ about
rudeness will be good for this group.
--
Jonathan
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>> ===
>>> JScript has features not in the ECMA standard. Some of the statements
>>> in the FAQ require qualification when applied to JScript.
>>> ===
>> Considered and rejected.
>
> I think what you mean here is that you're against it.
Exactly.
>> The same could be said about any other ECMAScript
>> implementation, most notably JavaScript.
>
> That's a good point. I've got the impression that JavaScript is much
> closer to the ECMA standard than JScript. What do you think, Thomas?
I think you are relying too much on your impressions and intuition and too
little on readily available facts.
> BTW, "2.1 What is ECMAScript?" in the FAQ tells us that JavaScript and
> JScript may differ in host objects (such as 'document').
Then that needs to be corrected as `document' is a DOM feature, not a
language feature.
> So I'm sorry, Thomas, but I won't follow your advice here.
You are free to continue making a fool of yourself here, of course. Just
don't assume anyone will continue to take the time to notice it and correct
you where you are wrong if you continue to post in this manner.
There is a difference between not knowing everything and politely asking
about the parts that one does not understand, and that which you display:
presumptuously stating something as as fact just for the purpose of stating
it and waiting for others to correct you.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Jonathan Fine
> Jonathan Fine wrote:
[snip]
> Then that needs to be corrected as `document' is a DOM feature, not a
> language feature.
>
>> So I'm sorry, Thomas, but I won't follow your advice here.
>
> You are free to continue making a fool of yourself here, of course. Just
> don't assume anyone will continue to take the time to notice it and correct
> you where you are wrong if you continue to post in this manner.
Thomas, I think you've snipped too much from the post you are replying
to. You've removed your advice, and the reason I gave for not following
your advice.
I am grateful to those who point out mistakes in what I post, and hope
that any future errors on my part on this list will be corrected.
I do, of course, prefer to be corrected with kindness and good humour.
--
Jonathan
Jorge
You think right, it would be good. But you're not alone here. And he's
well known for being systematically unable/unwilling to "Avoid being
unnecessarily rude", despite it being in the same point of the same
URL of the same FAQ he repeatedly advises others to read and follow. I
suspect that you're going to get nothing similar in return for your
good manners -I wouldn't overestimate him so much-, nevertheless, I
wish you good luck.
--
Jorge
Jonathan Fine
Thomas knows a lot about JavaScript. It's a pity that other things get
in the way of he and I discussing it together.
--
Jonathan
matt prokes
concepts in javascript but at the end of the day javascript is a
functional language and attempting to graft OOP concepts on a
functional language is exactly that.. A graft..
Here is an example that would invalidate the classical OOP example
that I had described earlier.
var t = function(x){
this.call=function(){alert(x);};
this.change=function(r){x=r;};
}
Now by all appearances this appears to be a top level class with two
methods inside it.
var e = new t('test');
e.call();
alert: test
Its NOT though, this is a programming paradigm that has been created
to simulate OOP programming, that doesn't mean though that it is
invalid, wrong, or syntactically incorrect. Infact many programming
paradigms have been erected out of Javascript, and thats JUST FINE
(see YUI vs. JQuery)!
Here is an example that invalidated traditional OOP.
var x = new e.change("rrrrrrr");
e.call();
alert: rrrrrrr
Whoa! did we just create a closure out of a method? YES WE DID.
Javascript is a functional language, not OOP. The new keyword
basically means new closure! Any function can create a new closure,
with its own prototype, etc.
Yet our method didn't go anywhere, in-fact if you wanted to you could
do this.
e.change('hi');
e.call();
alert: hi
In the end its all about functional programming and expressing the
language as clear as possible. Everyone has their own way of getting
the job done. Really this shouldn't be an argument about who has the
more knowledge about javascript, its not about street cred, its about
helping people.
The Natural Philosopher
> Infact many programming
> paradigms have been erected out of Javascript, and thats JUST FINE
> (see YUI vs. JQuery)!
>
>
> In the end its all about functional programming and expressing the
> language as clear as possible. Everyone has their own way of getting
> the job done. Really this shouldn't be an argument about who has the
> more knowledge about javascript, its not about street cred, its about
> helping people.
Huh? had me fooled..;-)
Jonathan Fine
> Mmmmm actually pointed ears is right, you can simulate traditional OOP
> concepts in javascript but at the end of the day javascript is a
> functional language and attempting to graft OOP concepts on a
> functional language is exactly that.. A graft..
Most people on the thread have said that JavaScript doesn't have
built-in classes, but that you can build code that provides class-like
behaviour. I think there's a consensus here.
I also agree that any 'class-building' in JavaScript must be aware of
the practical implications of relevant JavaScript fundamentals.
> Here is an example that would invalidate the classical OOP example
> that I had described earlier.
>
> var t = function(x){
> this.call=function(){alert(x);};
> this.change=function(r){x=r;};
> }
>
> Now by all appearances this appears to be a top level class with two
> methods inside it.
>
> var e = new t('test');
> e.call();
> alert: test
I'd have found your example clearer if you'd used the names 'get' and
'set'. My standard example of closures is:
function make_get_set(init){
return [
function(){return init;},
function(value){init = value}
];
}
I'd them write your example as
var T = function(init){
var tmp = make_get_set(init);
this.get = tmp[0];
this.set = tmp[1];
tmp = undefined; // Sort of optional.
}
What would make T a class would be adding methods to the prototype
object for T. Without that, T is little more than a record (which can
be useful).
> Its NOT though, this is a programming paradigm that has been created
> to simulate OOP programming, that doesn't mean though that it is
> invalid, wrong, or syntactically incorrect.
I don't find your example to be helpful. To me, it neither illustrates
a language feature nor arises from a real-world situation.
> Infact many programming
> paradigms have been erected out of Javascript, and thats JUST FINE
> (see YUI vs. JQuery)!
>
> Here is an example that invalidated traditional OOP.
>
> var x = new e.change("rrrrrrr");
> e.call();
> alert: rrrrrrr
>
> Whoa! did we just create a closure out of a method? YES WE DID.
> Javascript is a functional language, not OOP.
According to Wikipedia, JavaScript is NOT a functional language:
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Functional_languages
http://en.wikipedia.org/wiki/Functional_programming
BTW, Crockford in his book (p4) implies that JavaScript is a functional
programming language.
BTW, XSLT and TeX's macro expansion language are functional programming
languages.
But in JavaScript you can do assignment, and that's a real no-no in
functional programming.
> The new keyword
> basically means new closure! Any function can create a new closure,
> with its own prototype, etc.
Well, I prefer to think of it as a complex way of adding an object to
the prototype/inheritance tree, whose parent is the
Constructor.prototype. And in addition to adding the object supplying
an initialisation.
There are other ways to make a closure. It's really easy to make a
closure in a function
// Top level.
var stack = [];
var push = function(obj){
stack.push(obj);
};
Now do
push(0);
and there's a closure going on (although not a sensible or useful one).
>
> Yet our method didn't go anywhere, in-fact if you wanted to you could
> do this.
>
> e.change('hi');
> e.call();
> alert: hi
> In the end its all about functional programming and expressing the
> language as clear as possible. Everyone has their own way of getting
> the job done. Really this shouldn't be an argument about who has the
> more knowledge about javascript, its not about street cred, its about
> helping people.
I agree that to go far in JavaScript programming you have to understand
closures. But you also have to understand the prototype/inheritance
tree and the behaviour of new (or create). And quite a few other things
besides.
I'd include in this list an ability to program classes and inheritance.
--
Jonathan
Dr J R Stockton
view.co.uk>, Sat, 1 Aug 2009 00:06:18, Jonathan Fine <jf...@pytex.org>
posted:
>
>As I recall from yesterday, I thought that first sentence was fairly
>good. It's a real shame that the ECMA standard is not available as
>HTML. Then we'd be able to link to it.
It is available (unless recently withdrawn) as PDF, which can be linked
to, and also downloaded.
The FAQ has links to it. My site has links to it. The first result of
a Google search for ecma-262 HTML finds "ECMAScript Language
Specification (HTML version)". Cuil likewise. The Wikipedia page
"ECMAScript" has links to it.
The ISO/IEC version is as readily available, too.
It's a good idea to read the newsgroup c.l.j and its FAQ. See below.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Dr J R Stockton
view.co.uk>, Sat, 1 Aug 2009 18:07:01, Jonathan Fine <jf...@pytex.org>
posted:
>I am grateful to those who point out mistakes in what I post, and hope
>that any future errors on my part on this list will be corrected.
>
>I do, of course, prefer to be corrected with kindness and good humour.
Then you need to kill-file Thomas and perhaps David.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.
Dr J R Stockton
1 Aug 2009 17:23:16, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
>Considered and rejected.
Fortunately, you do not have the authority to determine that.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Dr J R Stockton
Aug 2009 13:16:39, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>>
>> Is it frequently asked? :)
>>
>> How about just:
>>
>> A: No, Javascript has no language support for traditional class based
>> programming. A programmer can, and often do, create objects and treat
>> them as being from the same "class", but this only works as long as
>> everybody stays with the abstraction. There is no language support to
>> enforce the class relations.
>
>AISB, that is wrong (if "Javascript" is understood, as you do, as a
>collection of ECMAScript implementations that include JScript).
The FAQ should primarily deal with "common javascript". JScript
extensions only work for a dwindling two-thirds of web users.
References to JScript extensions should clearly indicate their status.
In fact, those extensions are not JavaScript.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Peter Michaux
> Does JavaScript have classes and instances?
Big can of worms right there. The question is more of a problem from a
programming-language political perspective than from a practical
perspective.
I think the politically correct answer to this question would be about
the same for JavaScript as it is for plain old C. "The use of the
'class' and 'instance' concepts are possible but there is no specific
language support for these concepts." That answer is true for a lot of
varying definitions of "class" and "instance". Using the class and
instance concepts in JavaScript or C is not very difficult in a
program written in either language.
A non-politically correct answer would be that a JavaScript
constructor function and its prototype object is a "class" and the
resulting object from calling a constructor with the "new" keyword in
front of its name is an "instances".
Peter
Jonathan Fine
> In comp.lang.javascript message <UJSdnW0XZJV15e7XnZ2dnUVZ8lBi4p2d@bright
> view.co.uk>, Sat, 1 Aug 2009 00:06:18, Jonathan Fine <jf...@pytex.org>
> posted:
>> As I recall from yesterday, I thought that first sentence was fairly
>> good. It's a real shame that the ECMA standard is not available as
>> HTML. Then we'd be able to link to it.
>
> It is available (unless recently withdrawn) as PDF, which can be linked
> to, and also downloaded.
I wasn't clear enough. When I wrote "Then we'd be able to link to it" I
meant link to the first sentence (of 4.2.1 of the standard).
But you understood 'it' to mean the ECMA standard. What I wrote,
unfortunately, supports both interpretations.
>
> The FAQ has links to it. My site has links to it. The first result of
> a Google search for ecma-262 HTML finds "ECMAScript Language
> Specification (HTML version)". Cuil likewise. The Wikipedia page
> "ECMAScript" has links to it.
>
> The ISO/IEC version is as readily available, too.
According to http://standards.iso.org/ittf/licence.html, the ISO/IEC is
covered by the license:
===
You are downloading a single-user licence to store this file on your
personal computer. Under no circumstances may the electronic file you
are licensing be copied, transferred, or placed on a network of any sort
without the authorization of the copyright owner.
You may print out and retain one-only printed copy of the PDF file.
===
I don't like that.
> It's a good idea to read the newsgroup c.l.j and its FAQ.
BTW, I use Firefox on Ubuntu and out of the box PDF is downloaded to be
read by an external viewer (rather than in Firefox tab), and that is an
inconvenience.
--
Jonathan
John G Harris
wrote:
>On Jul 29, 2:36�pm, Jonathan Fine <jf...@pytex.org> wrote:
>
>> Does JavaScript have classes and instances?
>
>Big can of worms right there. The question is more of a problem from a
>programming-language political perspective than from a practical
>perspective.
>
>I think the politically correct answer to this question would be about
>the same for JavaScript as it is for plain old C. "The use of the
>'class' and 'instance' concepts are possible but there is no specific
>language support for these concepts."
Indeed, the first C++ compilers output C programs, which were then
compiled by a C compiler. That didn't stop the programs being OO and
having classes.
>That answer is true for a lot of
>varying definitions of "class" and "instance". Using the class and
>instance concepts in JavaScript or C is not very difficult in a
>program written in either language.
>
>A non-politically correct answer would be that a JavaScript
>constructor function and its prototype object is a "class"
No, no, no, no, no, no, no, no, no, no, no!
It's a class *definition* (of the imperative kind).
A class is a class of objects. Objects belong to a class, they aren't
created by it.
> and the
>resulting object from calling a constructor with the "new" keyword in
>front of its name is an "instances".
So when the class definition is executed in construct mode the result is
an instance.
John
--
John Harris
Jorge
> In article <XP2dnVnonegbEunXnZ2dnUVZ8u2dn...@brightview.co.uk>,
But don't take it for granted. Comprehension is more than reciting the
specs like a parrot.
>> It's a pity that other things get
>> in the way of he and me discussing it together.
While it was all right for Einstein to stick out his tongue at us,
this guy is no Einstein AFAICT and deserves no such kind of
privileges. Obviously, this cocky (when online) self-proclaimed hacker
(LOL) guy's confused mind thinks otherwise. The good news is that this
ugly attitude of him seems to be relaxing a bit as time goes on (at
least in the last year or so istm). I wish him to get totally well
soon :-)
--
Jorge.
matt prokes
Even the javascript wiki page says javascript is functional
http://en.wikipedia.org/wiki/JavaScript , maybe there is an error here
that needs to be corrected?
matt prokes
> > According to Wikipedia, JavaScript is NOT a functional language:http://en.wikipedia.org/wiki/List_of_programming_languages_by_categor...
>
> that needs to be corrected?
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Multiparadigm_languages
notes that javascript has functional aspects of programming. It may
not be truly functional like Haskell, but aspects of it are there.
John G Harris
wrote:
>Mmmmm actually pointed ears is right, you can simulate traditional OOP
>concepts in javascript but at the end of the day javascript is a
>functional language
This is how Wikipedia describes functional programming languages :
"In computer science, functional programming is a programming paradigm
that treats computation as the evaluation of mathematical functions and
avoids state and mutable data."
There's no way you can claim that javascript has no state. Global
variables carry a global state and objects carry local states. That's
what properties do and they are at the heart of javascript.
John
--
John Harris
Jonathan Fine
Thanks, Matt. I think there is an error there.
I assume you refer to:
<quote>
Functional
first-class functions
Functions are first-class; they are objects themselves. As such,
they have properties and can be passed around and interacted with like
any other object.
inner functions and closures
Inner functions (functions defined within other functions) are
created each time the outer function is invoked, and variables of the
outer functions for that invocation continue to exist as long as the
inner functions still exist, even after that invocation is finished
(e.g. if the inner function was returned, it still has access to the
outer function's variables) � this is the mechanism behind closures
within JavaScript.
[...]
JavaScript is also considered a functional programming language
like Scheme and OCaml because it has closures and supports higher-order
functions.
</quote>
I agree with it all except the last sentence.
In addition, "JavaScript is considered ..." uses the passive voice
inappropriately. Considered by who? Is the view correct?
--
Jonathan
Peter Michaux
> On Sat, 1 Aug 2009 at 17:07:47, in comp.lang.javascript, Peter Michaux
> wrote:
>
> >On Jul 29, 2:36 pm, Jonathan Fine <jf...@pytex.org> wrote:
>
> >> Does JavaScript have classes and instances?
>
> >Big can of worms right there. The question is more of a problem from a
> >programming-language political perspective than from a practical
> >perspective.
>
> >I think the politically correct answer to this question would be about
> >the same for JavaScript as it is for plain old C. "The use of the
> >'class' and 'instance' concepts are possible but there is no specific
> >language support for these concepts."
>
> Indeed, the first C++ compilers output C programs, which were then
> compiled by a C compiler. That didn't stop the programs being OO and
> having classes.
>
> >That answer is true for a lot of
> >varying definitions of "class" and "instance". Using the class and
> >instance concepts in JavaScript or C is not very difficult in a
> >program written in either language.
>
> >A non-politically correct answer would be that a JavaScript
> >constructor function and its prototype object is a "class"
>
> No, no, no, no, no, no, no, no, no, no, no!
I wrote it was politically incorrect ;-)
> It's a class *definition* (of the imperative kind).
>
> A class is a class of objects. Objects belong to a class, they aren't
> created by it.
It depends on the definition of the word "class". Some definitions are
better than others. There isn't a universally accepted definition and
a word can be overloaded to have multiple definitions depending on
context. When I say "nine" I could be meaning "the numeral nine" or
"the number nine" and the context completes what I'm saying
(hopefully.) When I say "class" I could be meaning "the class
definition" or "the class of objects" and the context completes what
I'm saying (hopefully.) Because "class" is known to be overloaded in
common usage, trying to force everyone to use a particular definition
is futile. It won't happen. Better to use a longer more descriptive
phrase when better information is necessary.
Peter
Thomas 'PointedEars' Lahn
> Dr J R Stockton wrote:
>> positive answer as in the first sentence of 16262 4.2.1.
>
> As I recall from yesterday, I thought that first sentence was fairly
> good. It's a real shame that the ECMA standard is not available as
> HTML. Then we'd be able to link to it.
(Which standard? ECMA has published a number of them.)
Assuming you refer to ECMA-262 Edition 3:
<http://lmgtfy.com/?q=ecmascript+html>
However, "someone" needs to take the time to compare this inofficial HTML
version of against the original to see if it was authoritative enough.
However, in general it is also possible to link to pages of a PDF document
if the plugin is Adobe Reader or a compatible application, see
<http://allmyfaqs.net/faq.pl?Link_to_a_PDF_page>
Try it here:
<http://www.mozilla.org/js/language/E262-3.pdf#page=3>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Osmo Saarikumpu
> People come here seeking *guidance*.
Maybe some do, but if I'm not misguided, that is not the raison
d'être of the NG. IOW, CLJ is not a help desk, it's a forum for
discussion about JS.
<FAQENTRY>
Maybe the FAQ should make this (what is clj for) point more explicit?
</FAQENTRY>
Anyways, before asking for help in a NG, the guidance seeker is
expected to read the group's FAQ.
Me thinks that it's quite marvelous that some kind folks like TL are
willing to help people by prioritizing their problems instead of
giving them the answers they are expecting to hear. IOW, the
guidance seekers do not "get pissed on from a great height", but are
given the medicine they most desperately need. Sure, it may taste
like crap, but if I don't swallow it, I won't get cured.
I view folks like TL as good doctors, which care more about the
patient than their own comfort. This in spite of all the bitching
and ungratefulness they get for doing so.
BR, Osmo
Jonathan Fine
> Jonathan Fine wrote:
>> Dr J R Stockton wrote:
>>> The extended Subject accommodates that, and also encourages a more
>>> positive answer as in the first sentence of 16262 4.2.1.
>> As I recall from yesterday, I thought that first sentence was fairly
>> good. It's a real shame that the ECMA standard is not available as
>> HTML. Then we'd be able to link to it.
>
> (Which standard? ECMA has published a number of them.)
>
> Assuming you refer to ECMA-262 Edition 3:
>
> <http://lmgtfy.com/?q=ecmascript+html>
This resolves to:
http://bclary.com/2004/11/07/
Thanks very much, Thomas. Pretty much what I was looking for. Now I
can link like this:
http://bclary.com/2004/11/07/#a-4.2.1
> However, "someone" needs to take the time to compare this inofficial HTML
> version of against the original to see if it was authoritative enough.
Except, as you say, it might have errors. I dare say the translator,
Bob Clary, has been diligent and has checked for errors.
> However, in general it is also possible to link to pages of a PDF document
> if the plugin is Adobe Reader or a compatible application, see
> <http://allmyfaqs.net/faq.pl?Link_to_a_PDF_page>
>
> Try it here:
> <http://www.mozilla.org/js/language/E262-3.pdf#page=3>
Yes, I know all this. But as I said, on my default Ubuntu PDF is
downloaded rather than opened in a browser. And in any case I'd like to
like to a document fragment, not a page.
--
Jonathan
Jonathan Fine
> IOW, the guidance seekers
> do not "get pissed on from a great height", but are given the medicine
> they most desperately need. Sure, it may taste like crap, but if I don't
> swallow it, I won't get cured.
The analogy is not so good. I can choose to take or not take the
medicine a doctor prescribes for me. And compulsory medication is a
humiliation.
Whereas rude remarks take effect moments after the message is opened.
The FAQ says:
Avoid being unnecessarily rude,
but do not complain about other rude posts.
Are you arguing, Osmo, that this advice should not apply to experts
dispensing medicine?
I think, or at least hope, that most people can be helped without being
rude to them.
--
Jonathan
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jonathan Fine wrote:
>>> Dr J R Stockton wrote:
>>>> The extended Subject accommodates that, and also encourages a more
>>>> positive answer as in the first sentence of 16262 4.2.1.
>>> As I recall from yesterday, I thought that first sentence was fairly
>>> good. It's a real shame that the ECMA standard is not available as
>>> HTML. Then we'd be able to link to it.
>> (Which standard? ECMA has published a number of them.)
>>
>> Assuming you refer to ECMA-262 Edition 3:
>>
>> <http://lmgtfy.com/?q=ecmascript+html>
>
> This resolves to:
> http://bclary.com/2004/11/07/
>
> Thanks very much, Thomas. Pretty much what I was looking for. Now I
> can link like this:
> http://bclary.com/2004/11/07/#a-4.2.1
>
>> However, "someone" needs to take the time to compare this inofficial HTML
>> version of against the original to see if it was authoritative enough.
>
> Except, as you say, it might have errors. I dare say the translator,
> Bob Clary, has been diligent and has checked for errors.
>
>> However, in general it is also possible to link to pages of a PDF document
>> if the plugin is Adobe Reader or a compatible application, see
>> <http://allmyfaqs.net/faq.pl?Link_to_a_PDF_page>
aptitude show mozplugger
(However, I am currently using Evince as viewer application which does not
appear to support this referencing.)
>> Try it here:
>> <http://www.mozilla.org/js/language/E262-3.pdf#page=3>
>
> Yes, I know all this. But as I said, on my default Ubuntu PDF is
> downloaded rather than opened in a browser. And in any case I'd like to
> like to a document fragment, not a page.
Read again.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
The Natural Philosopher
> Osmo Saarikumpu wrote:
>
>> IOW, the guidance seekers do not "get pissed on from a great height",
>> but are given the medicine they most desperately need. Sure, it may
>> taste like crap, but if I don't swallow it, I won't get cured.
>
> The analogy is not so good. I can choose to take or not take the
> medicine a doctor prescribes for me. And compulsory medication is a
> humiliation.
>
> Whereas rude remarks take effect moments after the message is opened.
>
> The FAQ says:
> Avoid being unnecessarily rude,
> but do not complain about other rude posts.
Ah, but surely in a perfect world if everybody read the FAQ they
wouldn't be in here asking damn fool questions.
It seems that its almost de facto that anyone here wont have read the
FAQ unless they were responsible for writing it.
SteveYoungGoogle
> Yes, I know all this. But as I said, on my default Ubuntu PDF is
> downloaded rather than opened in a browser. And in any case I'd like to
> like to a document fragment, not a page.
>
Maybe this is off topic but, as Thomas has also tried to point out, to
read .pdf files in your Ubuntu Firefox
you could install Adobe Reader Plugin
http://www.ubuntugeek.com/how-to-install-adobe-pdf-reader-with-plug-in-for-mozilla-firefox.html
or, if you want to use the open source .pdf reader Evince you could
install Mozplugger http://mozplugger.mozdev.org/index.html.
Regards, Steve.
The Natural Philosopher
> In article <h56281$vf2$4...@news.albasani.net>,
> The Natural Philosopher <t...@invalid.invalid> wrote:
>
>> Jonathan Fine wrote:
>>> Osmo Saarikumpu wrote:
>>>
>>>> IOW, the guidance seekers do not "get pissed on from a great height",
>>>> but are given the medicine they most desperately need. Sure, it may
>>>> taste like crap, but if I don't swallow it, I won't get cured.
>>> The analogy is not so good. I can choose to take or not take the
>>> medicine a doctor prescribes for me. And compulsory medication is a
>>> humiliation.
>>>
>>> Whereas rude remarks take effect moments after the message is opened.
>>>
>>> The FAQ says:
>>> Avoid being unnecessarily rude,
>>> but do not complain about other rude posts.
>> Ah, but surely in a perfect world if everybody read the FAQ they
>> wouldn't be in here asking damn fool questions.
>
> how real people operate. Someone who has an urgent question which needs
> fixing by tomorrow isn't going to think "Ooh! I know - I'll lurk around
> c.l.j for a month learning how to be a good boy in this NG, where the
> FAQ is, then I'll read it carefully, then I'll pose my question so that
> some expert can answer 'Yes' or as it might be 'No'", now are they.
> Likely they'll be posting questions in several locations, anyway.
>
> De facto, whatever the charter says, this is a helpdesk, because people
> post answers to questions here. If anyone doesn't like that, they better
> rename the NG as c.l.j.expertsonly or somesuch, or ensure that all
> newbie helpdesk-type questions are answered with a "Not a delpdesk,
> discussion only" type answer. Even saying "Refer to the FAQ" is a
> helpdesk response. A piss-poor one, yes, but a helpdesk answer
> nonetheless.
>
>> It seems that its almost de facto that anyone here wont have read the
>> FAQ unless they were responsible for writing it.
>
> experienced that myself.
>
..and as with unix man pages, its not so much a question reading the man
page, its knowing which one to read..
I am perfectly happy with a terse response like
try 'man lpadmin'
as a reply to 'how do I set up a printer from the command line'
Jorge
> (...)
> De facto, whatever the charter says, this is a helpdesk, because people
> post answers to questions here. If anyone doesn't like that, they better
But 'experts' ask questions too, is it their sole privilege ?
--
Jorge.
Jorge
> (...)
> In JavaScript the objects form a tree, whose
> root is Object.prototype. Each object inherits properties from its
> ancestors, all the way up to the root of the tree. (...)
That pictures it perfectly ! <FAQENTRY><FAQENTRY>
As even the global object inherits from Object.prototype... typing:
Object.prototype.x= 27; creates an 'inherited' global symbol x:
javascript:Object.prototype.x= 27; alert(x);
So, somehow, at the end of the scope chain there's not really the
global object, but the Object.prototype object.
--
Jorge.
Richard Cornford
> On Jul 30, 11:51 pm, Jonathan Fine wrote:
>> (...)
>> In JavaScript the objects form a tree, whose
>> root is Object.prototype. Each object inherits properties
>> from its ancestors, all the way up to the root of the
>> tree. (...)
>
> That pictures it perfectly ! <FAQENTRY><FAQENTRY>
>
> As even the global object inherits from Object.prototype... typing:
Not necessarily. The third paragraph of ECMA 262 3rd Ed. Section 15.1
says that the [[Prototype]] property of the global object is
"implementation-dependent". It may be the original value of -
Object.prototype -, but it could as easily be - null - or some other
value.
> Object.prototype.x= 27; creates an 'inherited' global symbol x:
>
> javascript:Object.prototype.x= 27; alert(x);
How many browsers did you try this on? The first I tried it on issued
the error "x is undefined".
> So, somehow, at the end of the scope chain there's not really
> the global object, but the Object.prototype object.
Not really. Where it works at all it is because the global object is
the last object on the scope chain, but the global object has
inherited properties from - Object.prototype -.
Richard.
Jonathan Fine
Nice one.
If you'd asked me what the output of
js> Object.prototype.x = 3
js> print(x)
was, I hope I'd give the correct answer.
Yes, the global object is an object that inherits up the tree.
All the same, I was surprised. Well, done, Jorge.
--
Jonathan
Jorge
wrote:
> (...)
> Not really. Where it works at all it is because the global object is
> the last object on the scope chain, but the global object has
> inherited properties from - Object.prototype -.
Therefore a symbol that is not found in any of the objects along the
scope chain, not even in the 'last' object of the scope chain, that
is, not even in the global object, will be ultimately be searched for
in Object.prototype, effectively making Object.prototype the truly
last object in the scope chain.
--
Jorge.
Jorge
>
> All the same, I was surprised. Well, done, Jorge.
You're welcome :-)
--
Jorge.
Malcolm Dew-Jones
: Malcolm Dew-Jones wrote:
: > Jonathan Fine (jf...@pytex.org) wrote:
: > : I thought this might be a good question for the FAQ. :
: > http://www.jibbering.com/faq/
: >
: > Replacing my own $0.01's worth, and certainly not intended as a complete
: > answer...
: Please don't. There are enough misinformation and misconceptions out of
: (mis)interpretation of terms already.
: > Javascript is very much an object oriented language, but neither the
: > language nor the interpreter have any feature called a "class".
: As for the interpreter, it remains to be seen a) what is meant by this and
: b) if it has a feature called a class.
I was trying to make clear that the dynamic nature of javascript means
that the algorithms used at runtime by an interpreter of the language must
be understood if you wish to understand a javascript program.
This distinction often appears to be lost.
: > To people familiar with languages like Java or C++ that might seem
: > contradictory. However, as in any OOP language, the concepts of class,
: > and instances within a class, are still very important, and Javascript
: > applications certainly do use classes of objects, and the individual
: > objects are instances of the class(es) to which they belong.
: Rubbish.
How is it rubbish?
: > The difference is that Javascript is a very dynamic language - its
: > objects simply do not require any formal predefined "thing" that you
: > might call a class. Instead, Javascript objects, within the runtime
: > environment of the Javascript interpreter, interact with each other in a
: > well defined manner that implements the class behaviours expected of any
: > object oriented language.
: Rubbish. You have never set up a custom prototype chain or heard of
: Function.prototype.call(), have you?
I play with Javascript for my own curiousity because it is a nice
language. I do not work with it, so my practical experience is less than
some others.
However, your brief sniplet condicts your own asertions. I said that the
behaviour of the interpretter has to be understood when understanding how
javascript objects relate to each other at run time. Your smiplet
mentions the prototype, which is an essential component of how it does
that, and mentions one example of the fact that a javascript program has a
great deal of dynamic control over how the object relationsships will be
interpretted, which is nothing more than a claim than javascript allows
programs to have runtime control over there own class structure. Which is
what I said originally, though not in those exact words.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn (Point...@web.de) wrote:
> : Malcolm Dew-Jones wrote:
> : > Jonathan Fine (jf...@pytex.org) wrote:
> : > : I thought this might be a good question for the FAQ. :
> : > http://www.jibbering.com/faq/
> : >
> : > language nor the interpreter have any feature called a "class".
>
> : As for the interpreter, it remains to be seen a) what is meant by this and
> : b) if it has a feature called a class.
>
> I was trying to make clear that the dynamic nature of javascript means
> that the algorithms used at runtime by an interpreter of the language must
> be understood if you wish to understand a javascript program.
No, what the interpreter (i.e. the Virtual Machine) does really does not
need to be understood in order to understood a javascript program (no matter
what "javascript" is supposed to mean.
> : > To people familiar with languages like Java or C++ that might seem
> : > contradictory. However, as in any OOP language, the concepts of class,
> : > and instances within a class, are still very important, and Javascript
> : > applications certainly do use classes of objects, and the individual
> : > objects are instances of the class(es) to which they belong.
>
> : Rubbish.
>
> How is it rubbish?
"Javascript applications" do _not_ "use classes of objects", and "the
individual objects" are _not_ "instances of the class(es) to which they belong."
> : > The difference is that Javascript is a very dynamic language - its
> : > objects simply do not require any formal predefined "thing" that you
> : > might call a class. Instead, Javascript objects, within the runtime
> : > environment of the Javascript interpreter, interact with each other in a
> : > well defined manner that implements the class behaviours expected of any
> : > object oriented language.
>
> : Rubbish. You have never set up a custom prototype chain or heard of
> : Function.prototype.call(), have you?
>
> [...]
> However, your brief sniplet condicts your own asertions.
Assuming you mean "contradicts": no, it does not.
> I said that the behaviour of the interpretter has to be understood when
> understanding how javascript objects relate to each other at run time.
> Your smiplet mentions the prototype,
(YSCIB.) No, I am talking about the prototype chain. As a consequence of
inheritance along the prototype chain and not according to the constructor's
prototype property, there is no "class" whatsoever an arbitrary object can
be related to. And the existence of Function.prototype.call() (and .apply)
means that any object may call any method of any other object (though not
always successfully), so there is no concept of class there as well.
Learn to quote.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jonathan Fine
> answer...
>
>
> language nor the interpreter have any feature called a "class".
I agree with both these statements.
> To people
> familiar with languages like Java or C++ that might seem contradictory.
And it also has inheritance (through the prototype/inheritance tree).
I'm used to programming in Python, and the idea that there is
inheritance but no inbuilt concept of class took me some time to get my
head around.
> However, as in any OOP language, the concepts of class, and instances
> within a class, are still very important, and Javascript applications
> certainly do use classes of objects, and the individual objects are
> instances of the class(es) to which they belong.
I'd say that when programming JavaScript it is often very helpful to
think of and construct classes of objects. As a working definition a
class of objects is a collection of objects that
a) have the same prototype object
b) have the same keys for for their own properties
c) behave in a uniform manner with respect to the method properties of
the prototype object.
> The difference is that Javascript is a very dynamic language - its objects
> simply do not require any formal predefined "thing" that you might call a
> class.
For me the key thing is that the concept of class is not an inbuilt
concept. It is a concept that the programmer implements, just as she
might implement the concept of a point.
> Instead, Javascript objects, within the runtime environment of the
> Javascript interpreter, interact with each other in a well defined manner
> that implements the class behaviours expected of any object oriented
> language.
This is, I think, saying in a different way the uniformity of behaviour
I mentioned above.
--
Jonathan
Dr J R Stockton
Aug 2009 08:05:37, The Natural Philosopher <t...@invalid.invalid> posted:
>
>It seems that its almost de facto that anyone here wont have read the
>FAQ unless they were responsible for writing it.
Those of the target audience who have successfully read the FAQ rarely
post to say that they don't need to ask the question.
Quoting the FAQ is an appropriate response to those, frequently
anonymous, who wander in and answer common questions badly.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Dr J R Stockton
view.co.uk>, Sun, 2 Aug 2009 22:19:49, Jonathan Fine <jf...@pytex.org>
posted:
>
>Except, as you say, it might have errors. I dare say the translator,
>Bob Clary, has been diligent and has checked for errors.
>
That might be quite easy, on the whole, since one can copy'n'paste the
rendered HTML and the rendered PDF into text files and do an automatic
comparison.
One would need a degree of normalisation of inessentials such as
whitespace (including some newlines), and DOS FC might well not suffice.
Note that the Clary version in that of December 1999, not the final of
March 2000.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Richard Cornford
> On Aug 3, 3:28 pm, Richard Cornford wrote:
>
>> (...)
>> Not really. Where it works at all it is because the global
>> object is the last object on the scope chain, but the global
>> object has inherited properties from - Object.prototype -.
>
> Therefore a symbol that is not found in any of the objects
> along the scope chain, not even in the 'last' object of the
> scope chain, that is, not even in the global object,
Identifier resolution against the scope chain uses the internal
[[HasProperty]] methods of the objects on the scope chain in order to
decide whether an object has a property with a given name. By those
criteria (i.e. the applicable ones) if the global object inherited a
property from an object on any prototype chain it may have then it
*has* that property.
Similar rues are applied to every object on the prototype chain and,
while most (i.e. Activation/Variable objects) don't have prototype
chains, some object on the chain could have prototype chains, so if
the prototype of global object is to be considered as being "in" the
scope chain then these other object's prototypes must also be
considered as being "in" the scope chain. At which point the structure
you have is no longer a chain at all, but rather resembles a comb with
most of teeth broken out or uneven.
> will be ultimately be searched for in Object.prototype,
> effectively making Object.prototype the truly last object
> in the scope chain.
That description breaks down if you consider assignment. Assignment to
an Identifier is supposed to result in the assignment of a value to a
property of an object in the scope chain (or to the global object if
no object in the scope chain 'has' (as determined by the object's
internal [[HasProperty]] method) a like-named property).
Significantly, if a object in the scope chain does not itself have
such a property but one of its prototypes does it is that object which
had value assigned as a named property, not the prototype on which the
property was actually found to reside.
In the event that the global object does not itself have a named
property that corresponds to an Identifier, but it does inherit such a
property from - Object.prototype - then assignment to that property
will not alter - Object.prototype -, it will alter the global object.
Thus, it makes no sense to consider - Object.prototype - as being "in
the scope chain". Instead it only really makes sense considering
object's prototypes as being aspects of the objects themselves;
aspects that influence the state and behaviour of the objects.
Scope chains are also usefully understood in terms of the specified
mechanism for their construction/creation; that the scope chain for an
execution context comes form the internal [[Scope]] property of the
executing function plus an Activation/Variable object (plus anything
added with a - with - statement). If you start trying to describe
scope chains in terms that include the prototypes of objects on the
scope chain you step away from the specified mechanism for their
construction/creation and end up muddying a subject that is not
sufficiently simple as to warrant additional obscurity.
At no point in the creation of a scope chain is the - Object.prototype
- an Activation/Variable object or an object in the list of objects
referred to by a function's internal [[Scope]] property (unless a -
with - statement is used to add it to the scope chain, at which point
is still could never be the "last object in the scope chain").
Prototypes may influence the behaviour of objects which are in a scope
chain in respect to identifier resolution. That influence does not
make them part of the scope chain, and claiming it does adds nothing
but worthless confusion to the subject.
Richard.
Osmo Saarikumpu
> The analogy is not so good. I can choose to take or not take the
> medicine a doctor prescribes for me. And compulsory medication is a
> humiliation.
Maybe not, but it's not about compulsory medication. The doctor
prescribes as he sees fit according to his learning and experience
and the patient is free to follow the doctors orders or not.
> Whereas rude remarks take effect moments after the message is opened.
Rudeness often lies in the eye of the beholder. USENET messages are
often short, aiming at the point. Gestures, facial expressions and
such are missing. We tend to get offended when we don't get the
expected response, don't we? At least we would like to have our sour
medicine with a sugar coating.
> The FAQ says:
> Avoid being unnecessarily rude,
> but do not complain about other rude posts.
>
> Are you arguing, Osmo, that this advice should not apply to experts
> dispensing medicine?
Surely not, I think it's very good advice. But I see a lot of
complaining about rudeness that is not socially incorrect in USENET
(as it may be when compared to a help desk).
Best wishes,
Osmo
Jorge
wrote:
I said 'inherited' global symbol, to imply that, among other things.
> Scope chains are also usefully understood in terms of the specified
> mechanism for their construction/creation; that the scope chain for an
> execution context comes form the internal [[Scope]] property of the
> executing function plus an Activation/Variable object (plus anything
> added with a - with - statement). If you start trying to describe
> scope chains in terms that include the prototypes of objects on the
> scope chain you step away from the specified mechanism for their
> construction/creation and end up muddying a subject that is not
> sufficiently simple as to warrant additional obscurity.
>
> At no point in the creation of a scope chain is the - Object.prototype
> - an Activation/Variable object or an object in the list of objects
> referred to by a function's internal [[Scope]] property (unless a -
> with - statement is used to add it to the scope chain, at which point
> is still could never be the "last object in the scope chain").
>
> Prototypes may influence the behaviour of objects which are in a scope
> chain in respect to identifier resolution. That influence does not
> make them part of the scope chain, and claiming it does adds nothing
> but worthless confusion to the subject.
I really appreciate when somebody takes the time to write down posts
like this (that's not always): it's ~impeccable, the form, the
contents and the manners(*). It makes of cljs a better place. When I
grow old(er) I'd love to be able to express myself in your language
the way you do :-))
Why don't you now move on to the thread "How to understand this form
(something) (param)" and post there a similar one ?
Like, e.g., discuss what's the single, truly characteristic aspect
that makes a closure a closure ?
Thanks,
(*) Not a single RTFM, etc !
--
Jorge.
Jonathan Fine
[snip]
>> The FAQ says:
>> Avoid being unnecessarily rude,
>> but do not complain about other rude posts.
>>
>> Are you arguing, Osmo, that this advice should not apply to experts
>> dispensing medicine?
>
> Surely not, I think it's very good advice.
Good. It applies to all, experts and newbies and in-between. (Although
if there is persistent or extreme rudeness I might express dislike.)
> But I see a lot of
> complaining about rudeness that is not socially incorrect in USENET
> (as it may be when compared to a help desk).
I don't know what you mean here. (Perhaps it doesn't matter than much,
though.)
--
Jonathan
Garrett Smith
Ah, no, that is not what Richard explained. Object.prototype is not the
last object on the scope chain.
To elaborate, the code:-
javascript:Object.prototype.x= 27; alert(x);
elerts "27" when the last object on the scope chain has a
Object.prototype in its *prototype*.
In "10.1.4 Scope Chain and Identifier Resolution", Step 3, a Reference
with base as *global object* Identifier as "x".
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
kangax
> On Aug 3, 6:22 pm, Jorge wrote:
>> On Aug 3, 3:28 pm, Richard Cornford wrote:
>>
>>> (...)
>>> Not really. Where it works at all it is because the global
>>> object is the last object on the scope chain, but the global
>>> object has inherited properties from - Object.prototype -.
>> Therefore a symbol that is not found in any of the objects
>> along the scope chain, not even in the 'last' object of the
>> scope chain, that is, not even in the global object,
>
> Identifier resolution against the scope chain uses the internal
> [[HasProperty]] methods of the objects on the scope chain in order to
> decide whether an object has a property with a given name. By those
> criteria (i.e. the applicable ones) if the global object inherited a
> property from an object on any prototype chain it may have then it
> *has* that property.
It's interesting that modern Gecko and WebKit -based implementations do
in fact set up `Object.prototype` to be in a prototype chain of "global
object".
In FF 3.0.x, for example this chain seems to look like:
window --> Window.prototype --> [object Global Scope Polluter] -->
Object.prototype --> null
It's not clear what the purpose of "Global Scope Polluter" object is;
all that I was able to observe is that its internal [[Class]] is "Global
Scope Polluter", that it has no own enumerable properties and that its
[[Prototype]] references `Object.prototype`.
In WebKit:
window --> [object DOMWindowPrototype] --> Object.prototype --> null
WebKit doesn't seem to expose window's [[Prototype]] (nor its
constructor) via a global property (as Gecko does with its
`Window.prototype`)
Opera doesn't provide any means to examine prototype chain (or at least
I don't know of any), but we can still deduce that it follows similar
pattern: it has at least one more object following `window` and has
`Object.prototype` somewhere in the chain as well.
window.hasOwnProperty('document'); // false
window intanceof Object; // true
[...]
--
kangax
Garrett Smith
Good find! I see you poked the browser and got something interesting.
Further LXR search lead to more info.
I read that "Global Scope Polluter" is the object that resolves element
identifiers.
|4466 //Someone is accessing a element by referencing its name/id in the
|4467 // global scope, do a security check to make sure that's ok.
In line 4550, I see:-
4549 {
4550 nsCOMPtr<nsIDOMDocument> dom_doc(do_QueryInterface(doc));
4551 nsCOMPtr<nsIDOMElement> element;
4552
4553 dom_doc->GetElementById(str, getter_AddRefs(element));
4554
4555 result = element;
4556 }
4557
4558 if (!result) {
4559 doc->ResolveName(str, nsnull, getter_AddRefs(result));
4560 }
I have never been very good with understanding Mozilla source code, and
I don't quite understand how it works, but I'll take a stab at what I
understand.
First, the scope chain and identifier resolution takes us to the global
object. From there, [[HasProperty]] is called. This results in a search
up the prototype chain. The outer window is reached, then the Global
Scope Polluter is reached and some sort of dispatch is called in context
of the inner window on "GlobalScopePolluterNewResolve", but only when
"GetCompatibilityMode" is true (not quirks mode).
What is "nsIXPCSecurityManager::ACCESS_GET_PROPERTY" ?
Can anyone explain "::JS_GetGlobalForObject"? What is that eventListener
for scripts? Is that related to recent discussions of script loading?
Understanding this requires C++ knowledge and I don't have that. What is
line 7360 doing?
7360 JSObject *scope = ::JS_GetGlobalForObject(cx, obj);
7361
7362 if (compile) {
7363 rv = manager->CompileScriptEventListener(script_cx, scope,
piTarget, atom,
7364 did_define);
7365 } else if (remove) {
7366 rv = manager->RemoveScriptEventListener(atom);
7367 } else {
7368 rv = manager->RegisterScriptEventListener(script_cx, scope,
piTarget,
7369 atom);
7370 }
7371
7372 return NS_FAILED(rv) ? rv : NS_SUCCESS_I_DID_SOMETHING;
7373 }
I know that eventually, the call to get on GlobalScopePolluter first
calls getElementById, then getElementsByName.
Mozilla source code explains how "inner" window uses the "outer"
window's prototype chain:
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIScriptContext.h#417
How identifiers are resolved on window:
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#2447
I'm trying to understand it.
kangax
> kangax wrote:
[...]
Interesting. Frankly, I have very little clue about what's going on here
myself. It would be nice to hear someone from Mozilla explain things in
more detail.
>
> Mozilla source code explains how "inner" window uses the "outer"
> window's prototype chain:
> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIScriptContext.h#417
>
>
> How identifiers are resolved on window:
> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#2447
>
>
> I'm trying to understand it.
MDC has some seemingly related information -
<https://developer.mozilla.org/en/DOM_Implementation_and_Scriptability>
('The Mozilla "window" object' section). Have you seen it?
I'll look into it too, when I have more time.
--
kangax