How to list the statement of all var ?

Thierry Loiseau

Hello all,

and Happy end year 2005 !

Well, I would like to obtain a list of all JavaScript var statement,
With "for...in" perharps ?

That is bellow my recent test here, but the problem is to management
theses :-((( I must to declare and use all variable with this scheme :

v['name']

Thanx for all suggestion !

================================================== ======================
<html>
<head>
<title>for...in (var)</title>
</head>
<body>
<script type="text/javascript">

</script>
</body>
</html>
================================================== ======================

Thierry
and best regards from France,

<http://www.google.com/maps?ll=45.128...5925,0.013087&
t=k&hl=fr>

PS : sorry for my bad english spoken :-(

Dec 26 '05 #1

Subscribe Post Reply

3531

Martin Honnen

Thierry Loiseau wrote:

Well, I would like to obtain a list of all JavaScript var statement,
With "for...in" perharps ?

That is bellow my recent test here, but the problem is to management
theses :-((( I must to declare and use all variable with this scheme :

v['name']

The var statement declares a variable (or more) and might additionally
initialize variables e.g.
var varName;
or
var varName = 'Kibology';

v['name'] is a property access but obviously no var statement.

The language itself does not have a "Code object model" which would
allow your script code to access the code itself in a structured way
where you could look for statements or statements of a certain type.

But global variables declared with the var statement will become
properties of the global object (which is the window object in
client-side browser script) and properties of an object can be
enumerated using the for..in statement if those properties are not
marked with the internal attribute DontEnum. As the var statement
definition does not specify that that internal DontEnum attribute should
be set for declared variables being created as properties an
implementation should make all those declared variables enumerable with
for..in.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Dec 26 '05 #2

Thierry Loiseau

Martin Honnen <ma*******@yahoo.de> wrote:

The var statement declares a variable (or more) and might additionally
initialize variables e.g.

I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

Thierry

Dec 26 '05 #3

Martin Honnen

Thierry Loiseau wrote:

Martin Honnen <ma*******@yahoo.de> wrote:

The var statement declares a variable (or more) and might additionally
initialize variables e.g.

I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

Sorry, I can't help, there is a French group fr.comp.lang.javascript as
far as I know where French is the main language, posting and reading
there might be more successful for you.
Google has it here:
<http://groups.google.com/group/fr.comp.lang.javascript?hl=en>
Hmm, I see you already post there, if that really does not help and you
want to post here then consider making a post with two languages,
English and French, here, that might then increase your chances that
someone here understands what you are looking for as you might have
someone read here who is fluent (enough) in French.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Dec 26 '05 #4

Thierry Loiseau wrote:

Martin Honnen <ma*******@yahoo.de> wrote:
The var statement declares a variable (or more) and might additionally
initialize variables e.g.

I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

"a state" - but this is a too vague term for the task description.
Based on the posted code you're trying to find either "valeur" (a
value) or "typage" (a type) - or both - of the v[i] elements. Could you
clarify please?
( Any recognizable version of the Shakespeare language goes just fine
;-)

Dec 26 '05 #5

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

Thierry Loiseau wrote:
Martin Honnen <ma*******@yahoo.de> wrote:
The var statement declares a variable (or more) and might additionally
initialize variables e.g.
I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

"a state" - but this is a too vague term for the task description.

Right ! Ok !
Based on the posted code you're trying to find either "valeur" (a
value) or "typage" (a type) - or both - of the v[i] elements. Could you
clarify please?
( Any recognizable version of the Shakespeare language goes just fine
;-)

Ok. Thank you for your post. Than my example, I would like to get value
of each !

With my script =

================================================== ======================
<html>
<head>
<title>for...in (var)</title>
</head>
<body>
<script type="text/javascript">

</script>
</body>
</html>
================================================== ======================

The result is :

================================================== ======================

titi = ' ' '
bleah = ' toto '
toto = ' bibi '
tutu = 109
annonce_fr = ' Bonne nouvelle année 2006 !! '
annonce_en = ' Happy new year 2006 !! '
v['tutu']+2 = 111
================================================== ======================

I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Thanx for all suggestion !

Thierry,
best regards from France

Dec 26 '05 #6

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

Thierry Loiseau wrote:
Martin Honnen <ma*******@yahoo.de> wrote:
The var statement declares a variable (or more) and might additionally
initialize variables e.g.
I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

"a state" - but this is a too vague term for the task description.

Right ! Ok !
Based on the posted code you're trying to find either "valeur" (a
value) or "typage" (a type) - or both - of the v[i] elements. Could you
clarify please?
( Any recognizable version of the Shakespeare language goes just fine
;-)

Ok. Thank you for your post. Than my example, I would like to get value
of each !

With my script =

================================================== ======================
<html>
<head>
<title>for...in (var)</title>
</head>
<body>
<script type="text/javascript">

</script>
</body>
</html>
================================================== ======================

The result is :

================================================== ======================

titi = ' ' '
bleah = ' toto '
toto = ' bibi '
tutu = 109
annonce_fr = ' Bonne nouvelle année 2006 !! '
annonce_en = ' Happy new year 2006 !! '
v['tutu']+2 = 111
================================================== ======================

I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Thanx for all suggestion !

Thierry,
best regards from France

Dec 26 '05 #7

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

Thierry Loiseau wrote:
Martin Honnen <ma*******@yahoo.de> wrote:
The var statement declares a variable (or more) and might additionally
initialize variables e.g.
I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

"a state" - but this is a too vague term for the task description.

Right ! Ok !
Based on the posted code you're trying to find either "valeur" (a
value) or "typage" (a type) - or both - of the v[i] elements. Could you
clarify please?
( Any recognizable version of the Shakespeare language goes just fine
;-)

Ok. Thank you for your post. Than my example, I would like to get value
of each !

With my script =

================================================== ======================
<html>
<head>
<title>for...in (var)</title>
</head>
<body>
<script type="text/javascript">

</script>
</body>
</html>
================================================== ======================

The result print in the page is :

================================================== ======================
titi = ' ' ' [string]
bleah = ' toto ' [string]
toto = ' bibi ' [string]
tutu = 109 [number]
annonce_fr = ' Bonne nouvelle année 2006 !! ' [string]
annonce_en = ' Happy new year 2006 !! ' [string]
v['tutu']+2 = 111
================================================== ======================

I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Thanx for all suggestion !

Thierry,
best regards from France

Dec 26 '05 #8

Thierry Loiseau wrote:

I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Array ("rangee") consists of arrayObject.length elements and you handle
them by their index which is positive integer:
v[10] = 'foo';
alert(v[10]);

The posted structure is *not* an array. So proper way to handle it
would be (one of possibilities):

var v=new Object(); // not Array!
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne nouvelle année 2006 !!";
v['annonce_en']="Happy new year 2006 !!";
etc. as you already do

And of course no one stops you from declaring separate variables which
are not parts of any higher structure:

var blah_blah_blah = "blah-blah-blah";

I guess you need to find a good French manual of JavaScript (I cannot
advise any).
For English reading you may visit:
<http://www.geocities.com/schools_ring/ArrayAndHash.html>

:-D ;-)

Dec 26 '05 #9

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

Thierry Loiseau wrote:
I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Array ("rangee") consists of arrayObject.length elements and you handle
them by their index which is positive integer:
v[10] = 'foo';
alert(v[10]);

The posted structure is *not* an array. So proper way to handle it
would be (one of possibilities):

var v=new Object(); // not Array!

Ok !
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne nouvelle année 2006 !!";
v['annonce_en']="Happy new year 2006 !!";
etc. as you already do

And of course no one stops you from declaring separate variables which
are not parts of any higher structure:

var blah_blah_blah = "blah-blah-blah";

I guess you need to find a good French manual of JavaScript (I cannot
advise any).
For English reading you may visit:
<http://www.geocities.com/schools_ring/ArrayAndHash.html>
Ok (too). So I make a long script to my (sorry in french) personal
homepage.

<http://astrophoto.free.fr/calculs/calculs.js>
:-D ;-)

Yep !

Thanx VK !

Thierry Loiseau
and Best regards
From France

Dec 26 '05 #10

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

Thierry Loiseau wrote:
I repeat : the problem is to management theses :-(((
So, I must to declare and use all variable with this strict scheme
(syntax, scheme is a good word ?) :

v['name']

Array ("rangee") consists of arrayObject.length elements and you handle
them by their index which is positive integer:
v[10] = 'foo';
alert(v[10]);

The posted structure is *not* an array. So proper way to handle it
would be (one of possibilities):

var v=new Object(); // not Array!

Ok ! But my script run with a good result, no ?
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne nouvelle année 2006 !!";
v['annonce_en']="Happy new year 2006 !!";
etc. as you already do

And of course no one stops you from declaring separate variables which
are not parts of any higher structure:

var blah_blah_blah = "blah-blah-blah";

I guess you need to find a good French manual of JavaScript (I cannot
advise any).
For English reading you may visit:
<http://www.geocities.com/schools_ring/ArrayAndHash.html>
Ok (too). So I make a long script to my (sorry in french) personal
homepage.

<http://astrophoto.free.fr/calculs/calculs.js>
:-D ;-)

Yep !

Thanx VK !

Thierry Loiseau
and Best regards
From France

Dec 26 '05 #11

Thierry Loiseau wrote:

So I make a long script to my (sorry in french) personal
homepage.

<http://astrophoto.free.fr/calculs/calculs.js>

Cool! So does everything work as expected now?

:-D ;-)

Yep !

Smilies were not to you directly, just a... conditional signature :-)

Dec 26 '05 #12

Thierry Loiseau

VK <sc**********@yahoo.com> wrote:

So I make a long script to my (sorry in french) personal
homepage.

<http://astrophoto.free.fr/calculs/calculs.js>
Cool! So does everything work as expected now?

From <http://astrophoto.free.fr/calculs/>
=> clic on button "simulateur copernic" and after onload, clic on
"astrophoto"... :-)))
=> clic on button "Lunes de Jupiter" and clic on the item "Repères", on
left, top, twice to view animation...

=> clic on button "visibilité des planètes", clic on the image-planete
then, there is a popup, and you see the position of this in the sky.
=> clic on button "astrophoto" to see the constelllation...

:-D ;-)

Yep !

Smilies were not to you directly, just a... conditional signature :-)

Argh, ok !-)

Best regards from France,

Thierry

PS : VK, do you speak french ?

Dec 26 '05 #13

Jasen Betts

On 2005-12-26, Thierry Loiseau <lo************@free.fr> wrote:

Martin Honnen <ma*******@yahoo.de> wrote:
The var statement declares a variable (or more) and might additionally
initialize variables e.g.

I'm shure "statement" is no well come in my first message :-(((
In french, "Etat" ?

I know very little French, "Etat" is like the english word "nation" ???

"a statement" is like "a thing said"

"var statement" in this context is a piece of javascript
that that starts with "var"

example:

var a=10,b=20;
Bye.
Jasen

Dec 26 '05 #14

RobG

Thierry Loiseau wrote:

VK <sc**********@yahoo.com> wrote:

[...]

The posted structure is *not* an array. So proper way to handle it
would be (one of possibilities):

var v=new Object(); // not Array!

Ok ! But my script run with a good result, no ?

Because Arrays are Objects, so you can do with them everything that
you can do with ordinary objects.

Arrays are a special objects with a property 'length' and a number of
special methods - splice, push, pop, concat et cetera - but otherwise
they are just like other objects.

VK suggested using an ordinary object because you weren't using the
special property or methods of an array.
[...]
--
Rob

Dec 27 '05 #15

Thierry Loiseau wrote:

Ok ! But my script run with a good result, no ?

It does... until when... because any JavaScript/JScript objext extends
Object constructor.

By the usage twist it is similar to:

function f1() {
with (arguments.callee) {
return arg1 + arg2;
}
}

f1.arg1 = 2;
f1.arg2 = 2;
alert(f1());

Here too you're declaring *function* f1 but overloading it as a
primitive Object. JavaScript is flexible enough for such and even more
weird things, but not would it be better to use the conventional way?

function f1(arg1, arg2) {
return arg1+arg2;
}

alert(f1(2,2));

You need to use hacks only when you have too. Otherwise you should use
the things with the intended purposes and in the intended way.
IMHighlyHO

Dec 27 '05 #16

VK <sc**********@yahoo.com> wrote:
The posted structure is *not* an array. So proper way to handle it
would be (one of possibilities):

var v=new Object(); // not Array!

Thierry Loiseau wrote: Ok ! But my script run with a good result, no ?

It does... until when... because any JavaScript/JScript objext extends
Object constructor.

So by the usage twist it is similar to:

function f1() {
with (arguments.callee) {
return arg1 + arg2;
}
}

f1.arg1 = 2;
f1.arg2 = 2;
alert(f1());

Here too you're declaring a "Function* object but using it as an Object
object. JavaScript is flexible enough for even more tricky things. But
wouldn't it be better to use the conventional way:

function f1(arg1, arg2) {
return arg1 + arg2;
}

alert(f1(2,2));

You should use hacks only if you have too otherwise you should use
things in the conventional way with the conventional purpose.
IMHighlyHO

Dec 27 '05 #17

Thomas 'PointedEars' Lahn

VK wrote:

Thierry Loiseau wrote:
Ok ! But my script run with a good result, no ?
It does... until when... because any JavaScript/JScript objext extends
Object constructor.

Wrong. What you maybe meant to say was that user-defined objects
inherit properties from the Object prototype which would be disabled
for an inheriting object as long as their name would be used as name
of a property of that object.
By the usage twist it is similar to:

function f1() {
with (arguments.callee) {
return arg1 + arg2;
}
}

f1.arg1 = 2;
f1.arg2 = 2;
alert(f1());

Here too you're declaring *function* f1 but overloading it as a
primitive Object.

Nothing is "overloaded" here. As in functional programming languages,
functions _are_ (first-class) objects in J(ava)Script/ECMAScript:
Function objects. Neither objects nor references are primitive values.
PointedEars

Dec 27 '05 #18

zwetan

Hello,

Well, I would like to obtain a list of all JavaScript var statement,
With "for...in" perharps ?

That is bellow my recent test here, but the problem is to management
theses :-((( I must to declare and use all variable with this scheme :

v['name']

Thanx for all suggestion !

[snip]

If you want to trace into an associative Array, use an object Object instead

in FF for ex:
---------------
var v=new Object();
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne fêtes de fin d'année !";
v['annonce_en']="Happy new year, this is the end of the year 2005...Hello
2006 !!";

document.write( "v:"+v.toSource() );
---------------

will trace
---------------
v:({titi:"", bleah:"toto", toto:"bibi", tutu:109, annonce_fr:"Bonne fêtes
de fin d'année !", annonce_en:"Happy new year, this is the end of the year
2005...Hello 2006 !!"})
---------------
if you want the same functionality in any browser you can also use my core2
library
http://www.burrrn.com/projects/core2.html

here an exemple
---------------
<html>
<body>
<head>
<script type="text/javascript" src="core2_v1.0.0_JS.js"></script>

<style type="text/css">

html
{
height: 100%;
overflow: hidden;
}

body
{
height: 100%;
margin: 0;
padding: 0;
background-color: #FFFFFF;
}

#TraceConsole
{
width: 600px;
/* height: 400%; */
text-align: left;
font-size: 12px;
/* font-family: monospace; */
/* font-family: tahoma, Verdana, Helvetica, Sans-Serif; */
font-family: courier,fixed,swiss,sans-serif;
border: 1px dotted #cccccc;
display: block;
}

</style>
</head>
<title>blah</title>
<html>
<div id="TraceConsole"></div>
<script type="text/javascript">

var v=new Object();
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne fêtes de fin d'année !";
v['annonce_en']="Happy new year, this is the end of the year 2005...Hello
2006 !!";

trace( "v:"+v.toSource( 0 ) );

</script>

</body>
</html>
---------------

will trace in the DIV
---------------
v:
{
titi:"",
bleah:"toto",
toto:"bibi",
tutu:109,
annonce_fr:"Bonne fêtes de fin d\'année !",
annonce_en:"Happy new year, this is the end of the year 2005...Hello
2006 !!"
}
---------------

Alternatively you could also use another way of organizing your local
strings

for exemple:
---------------
var AnnounceStrings = new Object();
AnnounceStrings.fr = new Object();
AnnounceStrings.en = new Object();

AnnounceStrings.fr.happyNewyear = "Bonne fêtes de fin d'année
!";
AnnounceStrings.fr.hello = "bonjour {0}";

AnnounceStrings.en.happyNewyear ="Happy new year, this is the end of the
year 2005...Hello 2006 !!";
AnnounceStrings.en.hello = "hello {0}";

trace( "AnnounceStrings:"+AnnounceStrings.toSource( 0 ) );

var userName = "toto";
var lang = "fr";

trace( "--------" );
trace( String.format( AnnounceStrings[ lang ].hello, userName ) );
---------------
will trace in the DIV
---------------
AnnounceStrings:
{
fr:
{
happyNewyear:"Bonne fêtes de fin d\'année !",
hello:"bonjour {0}"
},
en:
{
happyNewyear:"Happy new year, this is the end of the year
2005...Hello 2006 !!",
hello:"hello {0}"
}
}
--------
bonjour toto
---------------

HTH
zwetan

Dec 27 '05 #19

Thomas 'PointedEars' Lahn

zwetan wrote:

Well, I would like to obtain a list of all JavaScript var statement,
With "for...in" perharps ?
Please provide attribution of quoted material:

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
That is bellow my recent test here, but the problem is to management
theses :-((( I must to declare and use all variable with this scheme :

v['name']
[...] [snip]

If you want to trace into an associative Array, use an object Object
instead

Probably you meant to say "There are no associative Arrays in JS/ECMAScript.
What is achieved with associative arrays in other languages, is provided by
properties of objects and property accessors here."
in FF for ex:
---------------
var v=new Object();
v['titi']="";
v['bleah']='toto';
v['toto']='bibi';
v['tutu']=109;
v['annonce_fr']="Bonne fêtes de fin d'année !";
v['annonce_en']="Happy new year, this is the end of the year 2005...Hello
2006 !!";

document.write( "v:"+v.toSource() );
---------------

will trace
---------------
v:({titi:"", bleah:"toto", toto:"bibi", tutu:109, annonce_fr:"Bonne fêtes
de fin d'année !", annonce_en:"Happy new year, this is the end of the year
2005...Hello 2006 !!"})
---------------
No, it will not always, unless toSource() is user-defined.
if you want the same functionality in any browser
You meant to say "with any script engine" but even that would not be true.
you can also use my
core2 library
http://www.burrrn.com/projects/core2.html

here an exemple
---------------
<html>
<body>
<head>
Invalid examples are worthless. <URL:http://validator.w3.org/>
will trace in the DIV

IMHO, "tracing" is following traces, such as a stack trace where one call
on the stack leads to the next. So I do not see any tracing here, let alone
the "core2" library fulfilling its self-imposed requirement of "same API
everywhere (JavaScript, JScript, ActionScript, etc.)", considering e.g.
the untested use of document.getElementById() and proprietary `.innerHTML'.
I also see other examples of bad code style: an undeclared variable just to
call a function and then `delete' it, bad indentation, error-prone property
inference and so on. Certainly something that will make your day
interesting.
PointedEars
___________
[1] See <URL:http://en.wikipedia.org/wiki/Trace>, Computing, which you often
like to refer to on your Web site.

Dec 27 '05 #20

VK wrote:
It does... until when... because any JavaScript/JScript objext extends
Object constructor.
Thomas 'PointedEars' Lahn wrote:
Wrong. What you maybe meant to say was that user-defined objects
inherit properties from the Object prototype which would be disabled
for an inheriting object as long as their name would be used as name
of a property of that object.
Programming entities: Evolutionism or Creationism? :-)

I'm staing exclusively on the Evolutionism position here. There is the
initial protozoa Object() and everything else are branches of evolution
from this starting point. Date(), String(), Array(), myObject(),
myOtherObject() are all equally coming that protozoa despite their
evolution branches (thus property sets) can be twisted in the most
amazing ways.

Therefore arguments like "Array() is almost like Object() so no big
deal what to use" to me sounds like "daschund is really same kind as
buldog so no big deal what to buy".

I accept the possibility of other theories including the promoted
Selective Creationism, there all things are by themselves, and some
things should be considered as one entity (despite some differences)
because they've been created by Them to be one thing.

I still believe that my God is better :-)
Nothing is "overloaded" here.

I guess my usage of "overload" is not canonical. For me it's a way to
use the "other side" of things. Like create Array() and use it as
associative array via Object() side. Or store Function() arguments in
its Object() background (like in my sample), or force plus to works as
minus - something like this.

Dec 27 '05 #21

Thomas 'PointedEars' Lahn

VK wrote:

> VK wrote:
> It does... until when... because any JavaScript/JScript objext extends
> Object constructor.
Thomas 'PointedEars' Lahn wrote:

I thought you finally learned how to quote.
Wrong. What you maybe meant to say was that user-defined objects
inherit properties from the Object prototype which would be disabled
for an inheriting object as long as their name would be used as name
of a property of that object.

Programming entities: Evolutionism or Creationism? :-)

That is not a matter of philosophy or belief. The statement that
"JavaScript/JScript obje[c]t extends [the] Object constructor" is
simply wrong.

Nothing is "overloaded" here.

I guess my usage of "overload" is not canonical. [...]

Surprise, surprise!
PointedEars

Dec 27 '05 #22

zwetan

"Thomas 'PointedEars' Lahn" wrote:

zwetan wrote:
Well, I would like to obtain a list of all JavaScript var statement,
With "for...in" perharps ?
Please provide attribution of quoted material:

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
from my post I think is pretty clear to whom I answser (1 single poster)
cf
"Material quoted from the previous message is attributed to its author and
indented with a marker character (usually >). "

anyway point taken as you can see in the first line of this post.

Probably you meant to say "There are no associative Arrays in JS/ECMAScript. What is achieved with associative arrays in other languages, is provided by properties of objects and property accessors here."

Well I didn't get into all the details indeed,
yes there are no real associative Array in ECMAScript,
but you can obtain a similar functionality of associative Array using object
Object

but as I prefer to stay on topic, which if I remember well was
"I would like to obtain a list of all JavaScript var statement"

why should I go all the way to explain in lenghty details
the subtle differences between associative arrays and indexed arrays ?

Why don't you go into those details if you think these explanations are
missing
and should be stated to undertand better the problem at stake ?

for people interested in all the subtleties of Arrays in ECMAScript
I would advise those links
http://blogs.msdn.com/ericlippert/ar.../10/53376.aspx
http://blogs.msdn.com/ericlippert/ar.../12/53377.aspx
http://blogs.msdn.com/ericlippert/ar.../14/53383.aspx
http://blogs.msdn.com/ericlippert/ar.../21/53399.aspx
http://blogs.msdn.com/ericlippert/ar.../05/53452.aspx

Eric Lippert talk about the difference of implementation of Arrays in
JScript.NET
compared to JScript, but it can still be very usefull to apply this
knowledge
in other ECMAScript hosts, but as you can see the topic can be quite
lengthy.

in FF for ex: [snip]
No, it will not always, unless toSource() is user-defined.

"in FF" mean "in FireFox"...
you don't need to define the toSource method in FireFox afaik
it's natively implemented in the SpiderMonkey engine.
(and please don't point that I don't provide the exact version of the
engine)

I could understand that someone could not be familiar with the "FF"
abbreviation,
but to attribute my use of this abbreviation as a way to make a false
statement
is going a little too far don't you think ?

if you want the same functionality in any browser

You meant to say "with any script engine" but even that would not be true.

you know I just posted a comment to help someone,
I can not really phrase all my comments to suit your taste.

I meant "any browser" as "any browser host", as "any browser host
implementing ECMA-262 standard",
and I think you are really picky to jump on a detail like that.

Can you precise in what way "even that would not be true" ?
is it because of older browsers not implementing fully ECMA-262 3rd edition
or other browsers not implementing at all ECMA-262 and so not being able
to execute JavaScript ?

If for you my lack of details in my comment cause a problem,
you should a least apply this principle to your own comments,
just to not be vague as you apparently repproaching me.

I can accept critics, the problem with your comments is that you don't
explain clearly what your critic is about...

Yes off course "in any browser" was vague, but com'on
you know as me that not all ECMAScript implementations are made the same,
to discuss the problem of compatibility amongs all the browsers is a very
long thread in itself, I was just focusing on the problem that's all.

you can also use my
core2 library
http://www.burrrn.com/projects/core2.html

here an exemple
---------------
<html>
<body>
<head>

Invalid examples are worthless. <URL:http://validator.w3.org/>

at least I provide an exemple, and yes I don't pass all code that I write
from the top of my head trough a validator first

as I don't syntax check all my newsgroups post

I inverted 2 HTML tags..big deal
as sometimes I can inverse letters in words too because I write too fast
hey I'm just human

What is worhtless imho is someone spending his valuable time
pointing finger to all my little errors as if every human were robots and
perfect

are we here to help someone solve a problem
or to start a fight on what is worthless or not ?

will trace in the DIV
IMHO, "tracing" is following traces, such as a stack trace where one call
on the stack leads to the next. So I do not see any tracing here, let

alone the "core2" library fulfilling its self-imposed requirement of "same API
everywhere (JavaScript, JScript, ActionScript, etc.)", considering e.g.
the untested use of document.getElementById() and proprietary `.innerHTML'.

You see "tracing" in a different way that I see it and also in a different
context.

core2 goal is to be able to run anywhere there is a compliant ECMA-262
interpreter,
you can not implement "stack trace" everywhere due to the ECMA-262 standard
itself
which let the implementation of Function.prototype.toString at the
discretion of the
implementors.

Some hosts can introspect function body, some other hosts can not do that,
that's why the choice of not implementing "stack trace" has been made.
It's a choice that fill the requirement of the library, if that philosophy
does not suit you
well the code is open source and you are free to make a patch/diff/fork/etc.
..

And even if it could have been possible to implement "stack trace" for every
host,
I would have named it as a global function "StackTrace" to show the
difference of behaviour.

core2 is also a library which focus on ECMAScript programming, not the DOM
programming.

If you had taken the time to read some comments on the code,
http://live.burrrn.com/browser/ECMA-...uRRRn/core2.js
you could haves seen this
" yes it's an ugly hack :) "

I don't claim at all that the trace function is efficient, I just claim it
works
as it is on those browsers and as an ugly hack
a.. Mozilla, FireFox v1.0 (Windows)
b.. Mozilla, Mozilla v1.7.5 (Windows)
c.. Microsoft, Internet Explorer v6.0 (Windows)
d.. Opera Software, Opera v8.5 (Windows)
so yes I don't test getElementById(), I test ECMAScript code
targeted to work in any ECMA-262 environments, not only browser DOM.

And yes the library does not work as it is for IE v5.0
or is not yet tested on some other hosts, etc.

It is clearly stated on the project page and then i don't think I induce
people in error.

Following some of your links I see that you have developped libraries on
your own also,
so I suppose you know that sometimes you have to make choices about what
features to implement or not and to what extend to implement them and to how
to implement them.

I also see other examples of bad code style:
an undeclared variable just to call a function and then `delete' it,
does this cause a bug ?
bad indentation,
did you realize that the LIB releases have indeed their indentation striped
out
(as uncessary empty lines and code comments)
because their sole purpose are to be used as LIBraries,
if you want clean indented code with comments and all
you can check the DEVelopper releases,
or directly the source code in SVN.

error-prone property inference and so on.
I would have been glad that you had filled a bug report if you had seen
errors or bugs
http://live.burrrn.com/newticket

but afaik with the current code base and the current sets of unit tests and
the current tested hosts
I don't see any property inference, so if you can point where you see such
an error happening
I would just be happy to correct it.

If this comment is more about a difference of coding style, well...
I read some of your codes, you got your coding style
I understand why you do things like that
and I would not see myself to tell you that your coding style is bad
simply because you don't do things as I do.

The merit of a coding style is to be coherent amongs the whole code,
you are coherent amongs your code, I am coherent amongs my code,
doing things differently does not mean one way is better than another,
it's just a coding style.
Certainly something that will make your day interesting.
I understand that you are posting here for a long time and I respect that
but even if that was my 1st post on this newsgroup (which is not the case)
I don't really find all your comments on this particular topic that much
interesting

I would have prefered more constructive comments, but that's just me.
___________
[1] See <URL:http://en.wikipedia.org/wiki/Trace>, Computing, which you often like to refer to on your Web site.

indeed the first line I read is "The word trace has several meanings" :)

with a little advance I wish you an happy new year 2006 PointedEars

live long and prosper

zwetan

Dec 28 '05 #23

Thomas 'PointedEars' Lahn

zwetan wrote:

"Thomas 'PointedEars' Lahn" wrote:
zwetan wrote:
[...]
Probably you meant to say "There are no associative Arrays in JS/ECMAScript.

^^^^
Please get your NetNews posting software repaired:

<URL:http://insideoe.com/>

[repaired broken quotes]
What is achieved with associative arrays in other languages, is provided
by properties of objects and property accessors here."

Well I didn't get into all the details indeed,
yes there are no real associative Array in ECMAScript,
but you can obtain a similar functionality of associative Array using
object Object

but as I prefer to stay on topic,

This is on-topic as long it is about JS/ECMAScript.
which if I remember well was "I would like to obtain a list of all
JavaScript var statement"

why should I go all the way to explain in lenghty details
the subtle differences between associative arrays and indexed arrays ?
Why should you provide something that returns the names of properties
of an object when the question was about `var' statements?

var x, y, z;

should be _one_ entry in the requested list. Of course that is not possible
with property accessors.
Why don't you go into those details if you think these explanations are
missing and should be stated to undertand better the problem at stake ?
Because it has already been discussed at great length here before.
[...]
> in FF for ex: No, it will not always, unless toSource() is user-defined.

"in FF" mean "in FireFox"...

It does not work this way in Firefox (1.5) without prototype augmentation,
or in JavaScript for that matter, and it never has.
you don't need to define the toSource method in FireFox afaik
True, there is native prototype.toSource() for several core objects but
it does returns something different than you suggest in all cases.
it's natively implemented in the SpiderMonkey engine.
Yes, but it does not do what you suggest.
(and please don't point that I don't provide the exact version of the
engine)
It does not and has never worked this way in any SpiderMonkey version.

> if you want the same functionality in any browser

You meant to say "with any script engine" but even that would not be
true.

you know I just posted a comment to help someone,
I can not really phrase all my comments to suit your taste.

Usage of exact terms are one important key to understanding.
I meant "any browser" as "any browser host", as "any browser host
implementing ECMA-262 standard", [...]
It would have been true if you wrote "any language that is an
ECMAScript _3_ implementation." What is a "browser host" anyway?
Can you precise in what way "even that would not be true" ?
is it because of older browsers not implementing fully ECMA-262 3rd
edition or other browsers not implementing at all ECMA-262
Yes.
and so not being able to execute JavaScript ?
The question conveys a misconception about ECMAScript and JavaScript.
ECMAScript (3) !== JavaScript (1.5).

> you can also use my
> core2 library
> http://www.burrrn.com/projects/core2.html
>
> here an exemple
> ---------------
> <html>
> <body>
> <head>

Invalid examples are worthless. <URL:http://validator.w3.org/>

at least I provide an exemple, and yes I don't pass all code that I write
from the top of my head trough a validator first

If you are not able to write Valid markup from the top of your head (which
is a sure sign of insufficient experience), you should validate the result
first, because bad examples are copied by the uninitiated and end up in bad
code.
as I don't syntax check all my newsgroups post
I do not either. That is not the point.
I inverted 2 HTML tags..big deal
as sometimes I can inverse letters in words too because I write too fast
hey I'm just human
The rest of your markup is not Valid, too.
What is worhtless imho is someone spending his valuable time
pointing finger to all my little errors as if every human were
robots and perfect
/You/ _posted_ the example.
are we here to help someone solve a problem
or to start a fight on what is worthless or not ?
Examples with not Valid markup are worthless, because script code can only
operate reliably on Valid markup. That is a fact, not something that can
or should be fought about.

> will trace in the DIV

IMHO, "tracing" is following traces, such as a stack trace where one call
on the stack leads to the next. So I do not see any tracing here, let
alone the "core2" library fulfilling its self-imposed requirement of
"same API everywhere (JavaScript, JScript, ActionScript, etc.)",
considering e.g. the untested use of document.getElementById() and
proprietary `.innerHTML'.

You see "tracing" in a different way that I see it and also in a different
context.

You are misusing the word. There is nothing traced here at all. Maybe
I would have concured if you provided a serialization of the properties,
that is, show what steps are executed or serialize each known property
value (including those that are not enumerable) until there would only
be primitive values. That would be some kind of tracing, following the
trace from one property to the primitive value. So a trace of

x = {y: [/z/]};

could look like

x = new Object();
x.y = new Array();
x.y[0] = new RegExp("z");

or

x = {
y: Array
{
"0": RegExp
{
...
source: "z"
...
},
length: 1
...
}
};
core2 goal is to be able to run anywhere there is a compliant ECMA-262
interpreter,
An implementation conforming to ECMAScript _Edition 3_.
[...]
You are winding around the issue.

I also see other examples of bad code style:
an undeclared variable just to call a function and then `delete' it,

does this cause a bug ?

No, but it rightfully causes a warning in the JavaScript console. Variables
should be declared. With your code, assuming an ECMAScript 3 compliant
script engine is used,

(function(...)
{
// ...
})(...);

sufficed. There is no need for the undeclared global variable, hence
no need for `delete'.

bad indentation,

did you realize that the LIB releases have indeed their indentation
striped out
(as uncessary empty lines and code comments)

No, but that is not the point. You should and could have stripped it
better then.
because their sole purpose are to be used as LIBraries,
if you want clean indented code with comments and all
you can check the DEVelopper releases,
or directly the source code in SVN.
What are you talking about?

The developer release is just as badly indented:

| _global.trace = function( txt )
| {
| txt = String( txt );
| /* note:
| if you want to trace in a DIV layer inside the HTML page.
| Better if you want to trace a lot in the large.
| (yes it's an ugly hack :))

An ugly hack that is unnecessary, for `textarea' elements exist.

| */
| var tc = document.getElementById( "TraceConsole" );
| var clean = tc.innerHTML.replace( "<pre>", "" );
| clean = clean.replace( "</pre>", "" );
| tc.innerHTML = "<pre>"+clean+txt+"\r\n"+"</pre>";
| /* note:
| if you want to trace outside of the HTML page.
| Better for very few localized trace.
| */
| }

error-prone property inference and so on.

[...]
but afaik with the current code base and the current sets of unit tests
and the current tested hosts
I don't see any property inference, so if you can point where you see
such an error happening
I would just be happy to correct it.

The problem is that you tested with certain host environments and infer
from those special cases to the general one. What your code is lacking
to be almost bullet-proof is a feature-test _on run-time_ that the used
features, particularly the used DOM features, are supported.
[...]
The merit of a coding style is to be coherent amongs the whole code,
you are coherent amongs your code, I am coherent amongs my code,
doing things differently does not mean one way is better than another,
it's just a coding style.
That is not entirely true. Bad code style usually is based on
misconceptions and often results in unreliable code and/or code
that is harder to maintain.

I could provide more examples of that right from your code, but
that would not be worth the time required to be invested.

___________
[1] See <URL:http://en.wikipedia.org/wiki/Trace>, Computing, which you

often
like to refer to on your Web site.

indeed the first line I read is "The word trace has several meanings" :)

We are talking about applied computer science, do we not?
with a little advance I wish you an happy new year 2006 PointedEars
live long and prosper

Thanks, you too.
PointedEars

Dec 28 '05 #24

Thierry Loiseau

Jasen Betts <ja***@free.net.nospam.nz> wrote:

I know very little French, "Etat" is like the english word "nation" ???

Yep ! Sorry, I would like to write "état". Of course !-)
Zwetan, comment traduis-tu ce terme ?

Merci beaucoup à tous !

Thierry

Dec 28 '05 #25

zwetan

"Thomas 'PointedEars' Lahn" wrote:
[snip]

why should I go all the way to explain in lenghty details
the subtle differences between associative arrays and indexed arrays ?
Why should you provide something that returns the names of properties
of an object when the question was about `var' statements?

because it's useless to obtain the value of a var statement
if you don't know to wich property it is associated...
var x, y, z;

should be _one_ entry in the requested list.
That's _your_ coding style

you got other ways of declaring vars
var x;
var y;
var z;

and when you declare variable inside a container
the var keyword is useless

var foobar = new Object();
foobar.x = 0;
foobar.y = 1;

writing "var foobar.x = 0;" is useless
the container "foobar" is already declared with var.

[snip]
Why don't you go into those details if you think these explanations are
missing and should be stated to undertand better the problem at stake ?

Because it has already been discussed at great length here before.

well instead of pointing my lack of precision concerning that matter
just point a reference to a previous posting discussing it

you think this discussion require such precision so _you_ sould point to the
reference, not me.

[...]
> in FF for ex:
No, it will not always, unless toSource() is user-defined.

"in FF" mean "in FireFox"...

It does not work this way in Firefox (1.5) without prototype augmentation,
or in JavaScript for that matter, and it never has.

I didn't tested with FireFox v1.5 yet

And as soon as i will test it for this particular host
I will be able to valid or invalid your comment.

I believe in unit tests not in biased individual with an agenda.

you don't need to define the toSource method in FireFox afaik

True, there is native prototype.toSource() for several core objects but
it does returns something different than you suggest in all cases.

If you have read what I suggest you would had seen that I suggest
to use an Object object instead of an Array object.

toSource either in native SpiderMoneky implementation or in my own
implementation
does not list array members other than the indexed elements
and this is for me a logic behaviour, if you don't understand why I can
explain it to you.

it's natively implemented in the SpiderMonkey engine.

Yes, but it does not do what you suggest.

Yes It does you just didn't pay attention to what I suggest.

(and please don't point that I don't provide the exact version of the
engine)
It does not and has never worked this way in any SpiderMonkey version.

yes it does, you should test it for yourself instead of being stubborn and
trying to prove at all cost that I have made a false statement.

[snip]
Usage of exact terms are one important key to understanding.

Yes and you are surely not doing that.

I meant "any browser" as "any browser host", as "any browser host
implementing ECMA-262 standard", [...]

It would have been true if you wrote "any language that is an
ECMAScript _3_ implementation." What is a "browser host" anyway?

so a host implementing ECMA-262 standard is not an ECMAScript 3
implementation ?

that's really funny to read :)

as far as I know there can be only ECMAScript 3 implementations
as the ECMAScript 4 standard is still as a draft and then not officialy
released...
[snip]
and so not being able to execute JavaScript ?
The question conveys a misconception about ECMAScript and JavaScript.
ECMAScript (3) !== JavaScript (1.5).

I never said that!
you interpreting this yourself thinking you're the only one making the
difference
between ECMAScript (the language as defined in the ECMA-262 3rd edition)
and JavaScript (the implementation of this language in Netscape/Mozilla
browsers).
[snip]
If you are not able to write Valid markup from the top of your head (which
is a sure sign of insufficient experience), you should validate the result
first, because bad examples are copied by the uninitiated and end up in bad code.

oh now I understand why you're commenting this way

you're no here to help someone solve a problem or discuss about code

you're here to point that I have "sure sign of insufficient experience"

this is laugthable

are you feeling so insecure about your own experience ?

[snip]
I inverted 2 HTML tags..big deal
as sometimes I can inverse letters in words too because I write too fast
hey I'm just human

The rest of your markup is not Valid, too.

when you look for a solution it's better to have not a perfect valid code
than no code at all

I think people are smart enougth to grab part of a solution amongs different
comments to write their own solution

there is no problem to point that I inversed some markups,
but the way you do it you only say that to be able to say
that I got "sure sign of insufficient experience",
you don't do that to help solve a problem
you do that to secure your own ego

at best this is childdish from your part

What is worhtless imho is someone spending his valuable time
pointing finger to all my little errors as if every human were
robots and perfect
/You/ _posted_ the example.

You posted no example at all, just unconstructive criticism

if so easy to make no errors when you don't post code at all

are we here to help someone solve a problem
or to start a fight on what is worthless or not ?
Examples with not Valid markup are worthless, because script code can only
operate reliably on Valid markup. That is a fact, not something that can
or should be fought about.

the fact is that you sound like a kid which have too much time on his hands
to pinpoint all those little things

I never said that unvalid markup was good, it just happen that while
writing those examples I inverted some tags...big deal!

[snip]
You are misusing the word. There is nothing traced here at all. Maybe
I would have concured if you provided a serialization of the properties,
I don't care if you concur or not, you're obviously not here to have a
constructive debate
about some code or some solution, you're just here to critic whatever you
can critic.

I provide a serialization of the properties, you're just so full of yourself
to not see it.
that is, show what steps are executed or serialize each known property
value (including those that are not enumerable) until there would only
you can not serialize properties marked with the dontEnum attribute
go read ECMA-262 3rd edition spec (chapter 8.6.1 , PDF p38/188).
be primitive values. That would be some kind of tracing, following the
trace from one property to the primitive value. So a trace of
x = {y: [/z/]};
the code do provide tracing, but perharps you don't know how to use that
kind of code.

could look like

x = new Object();
x.y = new Array();
x.y[0] = new RegExp("z");

or

x = {
y: Array
{
"0": RegExp
{
...
source: "z"
...
},
length: 1
...
}
};

it's the kind of tracing I got using core2 toSource methods and ToSource
global function
except that the RegExp object is traced as a regular object
[snip...I think you are the issue]
I also see other examples of bad code style:
an undeclared variable just to call a function and then `delete' it,

does this cause a bug ?

No, but it rightfully causes a warning in the JavaScript console.

Variables should be declared. With your code, assuming an ECMAScript 3 compliant
script engine is used,

(function(...)
{
// ...
})(...);

sufficed. There is no need for the undeclared global variable, hence
no need for `delete'.
a warning is not an error

my solution is totally valid, and if that does not please you
because you think you know everything and everydy should do as you say
well... :D

avoid falacious arguments like that, it start to really be boring to read
you

bad indentation,

did you realize that the LIB releases have indeed their indentation
striped out
(as uncessary empty lines and code comments)

No, but that is not the point. You should and could have stripped it
better then.

the point is you have no valid argument to tell me how I should
organize, build, etc. my own code

and seeing how you, you organize your own code,
sorry but I prefer to stick on my way of doing things.

I'm still free to do that right ?

because their sole purpose are to be used as LIBraries,
if you want clean indented code with comments and all
you can check the DEVelopper releases,
or directly the source code in SVN.

What are you talking about?

you don't read indented code in a compiled DLL right ?

comments, spaces, indentation...these are just to make the code readable by
developpers

the code do not need to be indented to be interpreted correctly
I don't do "readable" libraries I do "compact as possible" libraries
so I repeat, if you want to obtain readable code check the DEV release or
the SVN repository

or perharps you never used the Subversion tool (SVN) ?

The developer release is just as badly indented:
[snip]

no... really ???

if you think that your coding standard should be imposed to everyone
and that would automagically make all other coding standards "badly
indented"

you think wrong
but you're free to think whatever make you feel comfortable with yourself :)

error-prone property inference and so on.
[...]
but afaik with the current code base and the current sets of unit tests
and the current tested hosts
I don't see any property inference, so if you can point where you see
such an error happening
I would just be happy to correct it.

The problem is that you tested with certain host environments and infer
from those special cases to the general one.

either you're underestimating the amount of work behind my code
or either you try to impose your vision of things on my code requirements

yes I could take the time to try to explain you why things are build like
that in my code,
but I think you would not even read and just try again to impose your point
of view,
so I will save me the trouble and the time of doing that.
What your code is lacking
to be almost bullet-proof is a feature-test _on run-time_ that the used
features, particularly the used DOM features, are supported.
the unit tests are indeed run at runtime ...on each different hosts
the tests does not change depending on the host, they are the same for each
tested host

and I repeat again I don't test DOM features, I test ECMAScript features

trace/printf/document.write are just end points
dependant on the host not on ECMAScript

to include DOM unit tests, that will create errors on host not having a DOM
or force me to have 2 different branching: one for host having a DOM and one
for the other hosts

the goal of the library is to be portable as it is on different hosts either
with a DOM or not
because indeed one of the requirement (and feature) is to have the same API
everywhere.

you are focusing too much on the DOM, and this is totally oppposite to the
requirrement of the code.

[...]
The merit of a coding style is to be coherent amongs the whole code,
you are coherent amongs your code, I am coherent amongs my code,
doing things differently does not mean one way is better than another,
it's just a coding style.

That is not entirely true. Bad code style usually is based on
misconceptions and often results in unreliable code and/or code
that is harder to maintain.

oh mister guru please show me the ligth...

as it is now my code have no misconceptions, you can think that
and I can tell you, you're a just plain wrong

I don't claim that my code is perfect but I really start to be tired
of your worhtless comments that I see as personnal attack
just because you got an ego problem

my code is not unreliable because all the code is tested
and yes sure bug can occur, and then I would simply
add more tests concerning that particular bug and the bug will be solved
as any developper would do in any half-serious project...nothing special
here

the code is not harder to maintain
because I use a versioning system,
because I use a build system,
and because I use unit tests

but apparently you can not understand that :)
I could provide more examples of that right from your code, but
that would not be worth the time required to be invested.

arf.. no you prefer to invest your time in unconstructive and worthless
criticism
and well I should not be surprised as everybody know: troll do have pointed
ears

first, let me tell you that the example you have already provided are not
valid at all,
second, I highly doubt your capacity of providing such valid examples,
and third, I think my previous respect to your comments was misplaced and
only
occured because of the amount of your posting.

So yes you can post any big volume of criticism,
but as far as I know that does not prove anything about
the validity or invalidity of my code.

If you want to have constructive discussion about ECMAScript programming,
that would be always welcome, if you're only here to impose your point of
view
thinking you are always right about evrything, I'm afraid I will be force to
let you
discuss all that with yourself and just ignore your comments.

zwetan

Dec 28 '05 #26

zwetan

"Thierry Loiseau" wrote:

Jasen Betts <ja***@free.net.nospam.nz> wrote:
I know very little French, "Etat" is like the english word "nation" ???

Yep ! Sorry, I would like to write "état". Of course !-)
Zwetan, comment traduis-tu ce terme ?

I would translate it as "state" or perharps "status"

so to nail down this translation problem

"to list the state of all var"
can be interpreted as
listing the values of variables corresponding to their variable names
(and is possible to obtain in code with a for...in)

"to list the statement of all var"
could be interpreted as
listing the syntax notation that has been used to declare the variables
(and this is not possible from client code, possible if you modify the
script engine
which I think is not the goal here)

zwetan

Dec 28 '05 #27

Thomas 'PointedEars' Lahn

zwetan wrote:

"Thomas 'PointedEars' Lahn" wrote:
> why should I go all the way to explain in lenghty details
> the subtle differences between associative arrays and indexed arrays ?
Why should you provide something that returns the names of properties
of an object when the question was about `var' statements?

because it's useless to obtain the value of a var statement
if you don't know to wich property it is associated...
var x, y, z;

should be _one_ entry in the requested list.

That's _your_ coding style

you got other ways of declaring vars
var x;
var y;
var z;

Don't be ridiculous. The request was to return a list of all `var'
statements. Either is one, so a solution will have to take that into
account.
and when you declare variable inside a container
the var keyword is useless

var foobar = new Object();
foobar.x = 0;
foobar.y = 1;

writing "var foobar.x = 0;" is useless
the container "foobar" is already declared with var.
foobar.x and foobar.y are not variables, so they are not "variables
declared inside a container".
[snip]
> Why don't you go into those details if you think these explanations are
> missing and should be stated to undertand better the problem at stake ? Because it has already been discussed at great length here before.

well instead of pointing my lack of precision concerning that matter
just point a reference to a previous posting discussing it

It has been more than a handful of postings and threads. In fact, it is
discussed in almost every other thread because property accessors are a
key feature of the language.
you think this discussion require such precision so _you_ sould point to
the reference, not me.
Don't be ridiculous. Obviously you are the newbie here, so it is _your_
obligation to get informed before you post, not mine to inform you.

However, you may try
<URL:http://groups.google.com/groups?as_q=property+accessor&as_ugroup=comp.lang. javascript&scoring=d&filter=0>
and the like.

> [...]
>> > in FF for ex:
>> No, it will not always, unless toSource() is user-defined.
>
> "in FF" mean "in FireFox"...

It does not work this way in Firefox (1.5) without prototype
augmentation, or in JavaScript for that matter, and it never has.

I didn't tested with FireFox v1.5 yet

I am sorry, I was about to write "prototype.toString() has never ever
worked in JavaScript the way you suggested, for any core object." when
I recognized you referred to prototype.toSource(), which does work as
suggested in JavaScript. My bad.

> it's natively implemented in the SpiderMonkey engine.

Yes, but it does not do what you suggest.

Yes It does you just didn't pay attention to what I suggest.

Not enough, true. But it appears that I am not the only one here.

Usage of exact terms are one important key to understanding.

Yes and you are surely not doing that.

Because I mixed up toSource() with toString()? You must be kidding.

> I meant "any browser" as "any browser host", as "any browser host
> implementing ECMA-262 standard", [...]

It would have been true if you wrote "any language that is an
ECMAScript _3_ implementation." What is a "browser host" anyway?

so a host implementing ECMA-262 standard is not an ECMAScript 3
implementation ?

Yes, indeed.
that's really funny to read :)
I am happy that I could amuse you.
as far as I know there can be only ECMAScript 3 implementations
No, there can be and are ECMAScript Edition 1 implementations, ECMAScript
Edition 2 implementations, and there are scripting languages that resemble
ECMAScript implementations but are none.
as the ECMAScript 4 standard is still as a draft and then not officialy
released...
True, I was not referring to ECMAScript Edition 4.

But JFTR: JScript.NET (v7.0) implements ECMAScript Edition 4 features
including class-based inheritance despite its working draft status.
I do not know whether if is possible to use it in IE once .NET 1.0
support is installed.

> and so not being able to execute JavaScript ?

The question conveys a misconception about ECMAScript and JavaScript.
ECMAScript (3) !== JavaScript (1.5).

I never said that!

| is it because of older browsers not implementing fully ECMA-262 3rd
| edition or other browsers not implementing at all ECMA-262 and so not
| being able to execute JavaScript ?
[snip]

If you are not able to write Valid markup from the top of your head
(which is a sure sign of insufficient experience), you should validate
the result first, because bad examples are copied by the uninitiated and
end up in bad
code.

oh now I understand why you're commenting this way

No, you do not understand at all.
you're no here to help someone solve a problem
I am, I did and I will do.
or discuss about code
I am, I did and I will do.
you're here to point that I have "sure sign of insufficient experience"
Commenting on invalid code and bad code style inevitably includes that.
this is laugthable
No, it is not, as your examples and your code prove.
are you feeling so insecure about your own experience ?
That is nothing different than "Do you beat your wife every evening?"
You lose.
[...]
You are winding around again.

> What is worhtless imho is someone spending his valuable time
> pointing finger to all my little errors as if every human were
> robots and perfect

/You/ _posted_ the example.

You posted no example at all, just unconstructive criticism

No, I even pointed out a possible solution to avoid bad code (style).
if so easy to make no errors when you don't post code at all

Obviously you are not able to learn, let alone to read.
I will not waste any more time with you and your nonsense.
PointedEars

Dec 28 '05 #28

zwetan

"Thomas 'PointedEars' Lahn" wrote:

[snip]

Don't be ridiculous. The request was to return a list of all `var'
statements. Either is one, so a solution will have to take that into
account.

core2 toSource methods and ToSource global fuction just provide that
solution
I already said that by the way.

[snip]
foobar.x and foobar.y are not variables, so they are not "variables
declared inside a container".

a variable member declared inside a container object is called a property
but it's still a variable.

[snip]
you think this discussion require such precision so _you_ sould point to
the reference, not me.

Don't be ridiculous. Obviously you are the newbie here, so it is _your_
obligation to get informed before you post, not mine to inform you.

it's not a problem to be informed or not
it's a problem about you insisting on the first place
that I provide such explanation where it's not required

| > If you want to trace into an associative Array, use an object Object
| > instead
|
| Probably you meant to say "There are no associative Arrays in
JS/ECMAScript.
| What is achieved with associative arrays in other languages, is provided
by
| properties of objects and property accessors here."

here's what you are doing and that I really dislike,
you're focusing so much on showing off your JS culture
that you don't even pay attention to what you are answering

basically I'm just telling to the original poster
instead of declaring the associative array
with an Array object
| var v=new Array();

to use an Object object instead
| var v=new Object();

"associative array" here is not a statement of "yes there are real
associative array in JavaScript",
it's a common and short way to describe one kind of array behaviour amongs
others.

However, you may try
<URL:http://groups.google.com/groups?as_q..._ugroup=comp.l
ang.javascript&scoring=d&filter=0> and the like.

the original poster did not required such precision
you required them from me

I'm not here to follow your wishes...

you are the one being ridiculous going into that much lengthy commenting
for something the original poster didn't even ask about
and probably already knew

[snip]
Because I mixed up toSource() with toString()? You must be kidding.

ok I will quote one of your previous post smart guy

"Usage of exact terms are one important key to understanding."

which I answer

Reading a post, before answering to it, is always a good idea

but you were more applied to critic and surely did not have time to read
what I wrote

> I meant "any browser" as "any browser host", as "any browser host
> implementing ECMA-262 standard", [...] [snip]
as far as I know there can be only ECMAScript 3 implementations

No, there can be and are ECMAScript Edition 1 implementations, ECMAScript
Edition 2 implementations, and there are scripting languages that resemble
ECMAScript implementations but are none.

NO.

I talk about the ECMA-262 standard, there is only one official ECMA-262
standard,
the 3rd one...

again I quote you

"Usage of exact terms are one important key to understanding."

look at
http://www.ecma-international.org/pu...s/Ecma-262.htm

do you see any ECMA-262 1st or 2nd edition ?

browser implementing only the 1st or 2nd edition of that standard
are either dinosaurs or unsupported and then are irrelevant.

as the ECMAScript 4 standard is still as a draft and then not officialy
released...

True, I was not referring to ECMAScript Edition 4.

But JFTR: JScript.NET (v7.0) implements ECMAScript Edition 4 features
including class-based inheritance despite its working draft status.
I do not know whether if is possible to use it in IE once .NET 1.0
support is installed.

it's possible but it's kind of a hack as it require FullTrust on the web
client

see:
http://groups.google.com/group/micro...7fc58120?hl=en

and about ES4 (ECMAScript 4) implementation
you can also look for Mozilla Epimetheus, Macromedia ActionScript 2.0,
Macromedia Flex 2 ActionScript 3.0, Mono JScript, DotGNU JScript, etc.

again you asked to use exact terms

"Usage of exact terms are one important key to understanding."

> and so not being able to execute JavaScript ?

The question conveys a misconception about ECMAScript and JavaScript.
ECMAScript (3) !== JavaScript (1.5).

I never said that!

| is it because of older browsers not implementing fully ECMA-262 3rd
| edition or other browsers not implementing at all ECMA-262 and so not
| being able to execute JavaScript ?

a browser implementing the ECMA-262 standard
allow the browser to execute JavaScript code

not all browsers execute JavaScript 1.5 based on the SpiderMonkey engine

Internet Explorer use its own JScript engine
Safari have forked the Konqueror KJS engine
etc.

[snip]
No, I even pointed out a possible solution to avoid bad code (style).

no you didn't

you got your own conception of bad code style
and even if you are a longtime poster here
that does not mean your coding style is the only one
universaly being "good".

if so easy to make no errors when you don't post code at all

Obviously you are not able to learn, let alone to read.
I will not waste any more time with you and your nonsense.

here a french citation for you
"La culture c'est comme la confiture, moins on en a plus on l'étale."
(Pierre Desproges)

which could be translated to
"culture is like jam, the less one has the more it is spread out."

you created all that nonsense, not me

zwetan

Dec 29 '05 #29

Thomas 'PointedEars' Lahn

zwetan wrote:

"Thomas 'PointedEars' Lahn" wrote:
Don't be ridiculous. The request was to return a list of all `var'
statements. Either is one, so a solution will have to take that into
account.
core2 toSource methods and ToSource global fuction just provide that
solution

They appear to provide but a list where each element is an enumerable
property of an object, which is a completely different thing.

From "core2 v1.0.0.66 DEV for Browsers JavaScript",
release/dev/core2_v1.0.0_JS/buRRRn/core2/Object.js:269:

/* Method: toSource
Returns a string representing the source code of the object.
Parameters:
indent - optionnal, the starting amount of indenting
indentor - optionnal, the string value used to do the indentation
*/
Object.prototype.toSource = function( /*int*/ indent, /*String*/ indentor )
{
var member, source;
source = [];
if( indent != null )
{
indent++;
}
for( member in this )
{
if( this.hasOwnProperty( member ) )
{
if( this[member] === undefined )
{
source.push( member + ":" + "undefined" );
continue;
}
if( this[member] === null )
{
source.push( member + ":" + "null" );
continue;
}
source.push( member + ":" + this[member].toSource( indent,
indentor ) );
}
}
if( indent == null )
{
return( "{" + source.join( "," ) + "}" );
}
if( indentor == null )
{
indentor = " ";
}
if(indent == null )
{
indent = 0;
}
var decal = "\n" + Array.initialize( indent, indentor ).join( "" );
return( decal + "{" + decal + source.join( "," + decal ) + decal +
"}" );
}
From release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js:294:

/* GlobalFunction: ToSource
Allow you to dump the source of the Global Object scope.
example:
(code)
trace( ToSource( 0 ) );
(end)
see: <Object.toSource>
*/
_global.ToSource = function( /*int*/ indent, /*String*/ indentor )
{
var target, member, source;
source = [];
if( indent != null )
{
indent++;
}
for( member in _global )
{
if( isGlobalReserved( mm ) )
{
continue;
}
if( member == "__path__" )
{
continue;
}
if( _global.hasOwnProperty( member ) )
{
if( _global[member] === undefined )
{
source.push( member + ":" + "undefined" );
continue;
}
if( _global[member] === null )
{
source.push( member + ":" + "null" );
continue;
}
source.push( member + ":" + _global[member].toSource( indent,
indentor ) );
}
}
if( indent == null )
{
return( "{" + source.join( "," ) + "}" );
}
if( indentor == null )
{
indentor = " ";
}
if(indent == null )
{
indent = 0;
}
var decal = "\n" + Array.initialize( indent, indentor ).join( "" );
return( decal + "{" + decal + source.join( "," + decal ) + decal +
"}" );
}

(So much for your claim of proper indentation in the "developer sources" and
for your claim that using the Comma operator in `var' statements would be
but my coding style.)

Unfortunately, it is impossible to test that it does what you claim it would
do, because

| Error: mm is not defined
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js
| Line: 312

(|Warning: assignment to undeclared variable _introspectGlobal
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2.js
| Line: 21)

with

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>core2 Test</title>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2.js"
type="text/javascript"></script>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js"
type="text/javascript"></script>
<script type="text/javascript">
var x, y, z;

function _onload()
{
trace( ToSource( 0 ) );
}
</script>
</head>

<body onload="_onload();">
<div id="TraceConsole"></div>
</body>
</html>

on

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051224
Debian/1.5.dfsg-3 Firefox/1.5 Mnenhy/0.7.3.0

and there is no occurence of the word `mm' in the rest of the files that
would declare that variable. Maybe you can explain what I did wrong.
I already said that by the way.

Yes, you talk much.

foobar.x and foobar.y are not variables, so they are not "variables
declared inside a container".

a variable member declared inside a container object is called a property
but it's still a variable.

Utter nonsense. Read ECMAScript Edition 3, especially subsection 10.1.3.

It also talks volumes that your HTML documentation of the project refers to
prototype objects as "Classes". Why am I not surprised?

<URL:http://www.burrrn.com/documentation/core2/index/Classes.html>

So much for your understanding of the programming language(s) used.
PointedEars

Dec 29 '05 #30

zwetan

"Thomas 'PointedEars' Lahn" wrote:

zwetan wrote:
"Thomas 'PointedEars' Lahn" wrote:
Don't be ridiculous. The request was to return a list of all `var'
statements. Either is one, so a solution will have to take that into
account.
core2 toSource methods and ToSource global fuction just provide that
solution

They appear to provide but a list where each element is an enumerable
property of an object, which is a completely different thing.

humm ok you say it's completely different thing
can you provide a scenario of what you would expect ?

like: I got this code, if I trace this reference of code I would expect this
result, not that result.

toSource has been heavyly inspired by the SpiderMoneky engine toSource
functionality
but it can not be exactely the same as we are implementing it from
client-side source code
not directly in the host engine.

some limitations:
- impossibility to trace member marked as "DontEnum"
- no assignement of pointers to represent circular reference

some differences:
- choice to not trace the body of Function object
- choice to not implement toSource for REgEx object

From "core2 v1.0.0.66 DEV for Browsers JavaScript",
release/dev/core2_v1.0.0_JS/buRRRn/core2/Object.js:269:
[snip]

notice that to have full tracing you need all core object "toSource"
implementation
not only the Object.prototype.toSource

this is implemented as a polymprophic behaviour,
each core object having its own implementation of toSource

if you don't include the Array, Boolean, etc. toSource implementation
sure it could not work as expected.

From release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js:294:
[snip]
(So much for your claim of proper indentation in the "developer sources" and for your claim that using the Comma operator in `var' statements would be
but my coding style.)

for me the source code is properly indented, and as specified in
http://live.burrrn.com/wiki/CodingStandard
" As a general rule the coding standard to follow is the coding style of the
module owner. "

I will not impose my coding style to your code
and I expect you don't impose me your coding style in my code

I will not change the indentation of 30Kloc+ source code to please you.

see also
http://wiki.mozilla.org/Update:Devel...Best_Practices
" Coding standards should be chosen, not argued about. "

perharps you experiencing problems in indentation because
of the difference of CR/LF between Windows and Linux ?

Unfortunately, it is impossible to test that it does what you claim it would do, because

| Error: mm is not defined
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js
| Line: 312

yes that's a bug, referenced here
http://live.burrrn.com/ticket/14

a stupid bug that happened after the refactoring of some local variable

note that this bug is not patched yet because there are also some
refactoring going on
in the global ToSource function and also the GetObjectPath global function
which would add the little feature to be able to introspect core objects in
a better way

core2 v1.0.1 (planed for 2006/01/02) will solve all that
as a quick fix you can just replace "mm" local variable by "member".
(|Warning: assignment to undeclared variable _introspectGlobal
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2.js
| Line: 21)

the ECMAScript host where this code has been tested that you can see listed
here
http://www.burrrn.com/projects/core2.html
do not yeld such a warning

in brief, if the host where you're running the code is not included in the
tested hosts
sure some warning could be yeld, it just a matter of adding those hosts to
the test cycle.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>core2 Test</title>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2.js"
type="text/javascript"></script>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js"
type="text/javascript"></script>
stop here

that's why there is a DEV release and a LIB release

to save you trouble to include dozens of script files
you would be better using the library as 1 single file

<script src="release/lib/core2_v1.0.0_JS.js"
type="text/javascript"></script>

you can not just include part of the library, you have to include all the
files.
<script type="text/javascript">
var x, y, z;

function _onload()
{
trace( ToSource( 0 ) );
}
</script>
</head>

<body onload="_onload();">
<div id="TraceConsole"></div>
</body>
</html>

as you are including only parts of the core2 library
it surely does not work

core2 is about augmenting all the ECMAScript core objects,
this create a dependency on core2 itself,
it's all or nothing, you can not pick part of the core2 library.

This is a design choice, we stick to the objects we avoid global function,
it got its pros and cons, one of the pros is that it allow a lot of code
reuse,
one of the cons is that it force you to include all the files.
on

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051224
Debian/1.5.dfsg-3 Firefox/1.5 Mnenhy/0.7.3.0

ok, I can not test on Linux, but your case interest me
as the goal is to be able to run in any hosts and in particular any OS

I will add tests using Firefox v1.5 on windows
hoping that the windows version have a similar behaviour than the linux
version

this is an evolving project, the main part is stable (hence the versioning
1.0.0)
but there still could have some bugs or glitch that can be improved.

When core2 v1.0.0 was released Firefox v1.5 was still in beta for exemple.

and there is no occurence of the word `mm' in the rest of the files that
would declare that variable. Maybe you can explain what I did wrong.
except including just "_global.js" and "Object.js", you did nothing wrong

the "mm" local variable is a bug that I did not catch in time,
it will be solved for the core2 v1.0.1 release
[snip]
It also talks volumes that your HTML documentation of the project refers to prototype objects as "Classes". Why am I not surprised?

<URL:http://www.burrrn.com/documentation/core2/index/Classes.html>

So much for your understanding of the programming language(s) used.

first I use a 3rd party tool to generate the documentation: NaturalDoc
this tool is really good, but as it generate documentation not only for
ECMAScript languages
it uses common term used by other languages,
this tool use the term "class",
if you want to know my point of view concerning a good naming in ECMAScript
you can read that post here
http://www.zwetan.com/blog/ECMAScript/RaisingHell.html
"The main idea being that a prototype-based language allows to create object
without class, and that's why imho you can not use the class terminology
inside ECMAScript."

You will also notice that in my inline code comments I never use the terme
"class"
but the term "constructor" which is imho a better term to classify an
ECMAScript pseudo-class.
see for exemple
http://live.burrrn.com/browser/ECMA-.../NullObject.es

/* Constructor: NullObject
Utilitarian object allowing to treat
a null value as an object.

note:
usefull for some polymorphic situation.

see: <http://c2.com/cgi/wiki?NullObject>
*/
_global.NullObject = function()
{

}
zwetan

Dec 30 '05 #31

Thomas 'PointedEars' Lahn

zwetan wrote:

"Thomas 'PointedEars' Lahn" wrote:
zwetan wrote:
> "Thomas 'PointedEars' Lahn" wrote:
>> Don't be ridiculous. The request was to return a list of all `var'
>> statements. Either is one, so a solution will have to take that into
>> account.
>
> core2 toSource methods and ToSource global fuction just provide that
> solution They appear to provide but a list where each element is an enumerable
property of an object, which is a completely different thing.

humm ok you say it's completely different thing

Yes, indeed. Declared variables are properties of the Variable Object of
the execution context (ES3, 10.1.3), that is the Global Object in global
context. But not all properties are variables.

One simple example that makes this difference clear: the `delete' operator
(ES3, 11.4.1) can be applied to declared (that is, user-defined) variables
but it has no effect because those variables, or properties of the Variable
Object, have the DontDelete flag set during variable instantiation (ES3,
10.2 and 8.6.2.5). The `delete' operator can be applied to user-defined
properties of objects different from the Variable Object and always has
effect because those properties have _not_ been subject to variable
instantiation; they are _not_ variables.
can you provide a scenario of what you would expect ?

like: I got this code, if I trace this reference of code I would expect
this result, not that result.
function x()
{
var y = 23, z;
}
x.foo = 42;

A solution returning a list of the variables declared in the local context
of x() should return a list with the elements `y' and `z' (and maybe a
representation of their assigned value). A solution returning a list of
`var' statements in the local context of x() should return a list with
the only element

var y = 23, z;

A solution returning the enumerable properties of the Function object `x'
refers to (short: x) should at least return `foo', but not `y' or `z',
because the latter ones are properties of the Variable Object created when
the method is called and the local context is entered, not properties of x.
some limitations:
- impossibility to trace member marked as "DontEnum"
It is possible to "trace" known properties that have the DontEnum flag.
My ObjectInspector[1] does a pretty good job at that.
- no assignement of pointers to represent circular reference
I am not sure what you mean by that.

It is possible to determine that a property value is a reference
to the property owner. My ObjectInspector can do that.

[1]
<URL:http://pointedears.de/scripts/test/ObjectInspector/nightly/latest/index>
some differences:
- choice to not trace the body of Function object
So your library will _never_ be able to provide the solution the OP asked
for. In case you forgot: that was a list of all _`var' statements_.
- choice to not implement toSource for REgEx object
That is /your/ decision (one that I would not follow) and /your/ problem.
[...]
From "core2 v1.0.0.66 DEV for Browsers JavaScript",
release/dev/core2_v1.0.0_JS/buRRRn/core2/Object.js:269:
[snip]

notice that to have full tracing you need all core object "toSource"
implementation
not only the Object.prototype.toSource

this is implemented as a polymprophic behaviour,
each core object having its own implementation of toSource

if you don't include the Array, Boolean, etc. toSource implementation
sure it could not work as expected.

OMG. Are you telling me I have to include the whole Array.js for

| _global.ToSource = function( /*int*/ indent, /*String*/ indentor )
| {
| [...]
| var decal = "\n" + Array.initialize( indent, indentor ).join( "" );
| return( decal + "{" + decal + source.join( "," + decal ) + decal + "}"
| );
| }

which does nothing more than this?

| Array.initialize = function( /*int*/ index, value )
| {
| if( index == null )
| {
| index = 0;
| }
| if( value === undefined )
^^^^^^^^^
| {
| value = null;
| }
| var arr, i;
| arr = [];
| for( i=0; i<index; i++ )
| {
| arr.push( value );
| }
| return arr;
| }

BTW: This will break in IE before version 5.5 (as it was introduced
in JScript 5.5). typeof value == "undefined" will not break in any
current or previous IE version that is still of any use (as the
operator was introduced in JScript 1.0, IE 3.0).

So your statement in news:43**********************@news.wanadoo.fr

| core2 is also a library which focus on ECMAScript programming, not
| the DOM programming.

is of course utter nonsense as well. Not only because of referring to
"DOM programming", but because of referring to "ECMAScript programming";
ECMAScript is an _abstract_ language specification for language
implementations based on language features of JavaScript 1.1 and JScript
1.0. In the real world you have to deal with the implementations, mostly
and particularly those in HTML UA's script engines, that is to date,
JavaScript, JScript, the Opera implementation, and KJS. The Specification
can only provide guidance here, it does not tell exactly how things really
are. It is error-prone and potentially harmful to rely on it only.

From release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js:294:

[snip]

(So much for your claim of proper indentation in the "developer sources"

and

^^
for your claim that using the Comma operator in `var' statements would be
but my coding style.)
^^
for me the source code is properly indented, and as specified in
http://live.burrrn.com/wiki/CodingStandard
" As a general rule the coding standard to follow is the coding style of
the module owner. "

I will not impose my coding style to your code
and I expect you don't impose me your coding style in my code

I will not change the indentation of 30Kloc+ source code to please you.
It would not be to please /me/. /I/ certainly do not require that
from /you/.
see also
http://wiki.mozilla.org/Update:Devel...Best_Practices
" Coding standards should be chosen, not argued about. "
Non sequitur. This is the place for discussion.
perharps you experiencing problems in indentation because
of the difference of CR/LF between Windows and Linux ?
No, it is not because of newline delimiters, as you should know and probably
already do know anyway. It is of you indenting

statement
{
block
}

instead of

statement
{
block
}

and the like. You will find little support for the former indentation style
here or elsewhere (including JavaScript source code for Gecko) because it
is harder to recognize and therefore harder to maintain than the latter or
something more like that.
Unfortunately, it is impossible to test that it does what you claim it

would

^^
do, because

| Error: mm is not defined
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js
| Line: 312

yes that's a bug, referenced here
http://live.burrrn.com/ticket/14

a stupid bug that happened after the refactoring of some local variable

note that this bug is not patched yet because there are also some
refactoring going on

^^^^^^^^^^^^^^^^^^^^^^ in the global ToSource function and also the GetObjectPath global function
which would add the little feature to be able to introspect core objects
in a better way
(Will you fix your posting program or use a viable alternative? This
is hard to read! I have now skipped reformatting the quotation so that
you can see what you expect of your readers as what is wrapped there
was beyond the accepted 80 characters limit.)
core2 v1.0.1 (planed for 2006/01/02) will solve all that
as a quick fix you can just replace "mm" local variable by "member".
I call that an example of incompetent release schedule.

(|Warning: assignment to undeclared variable _introspectGlobal
| Source file:
| file:///tmp/core2/release/dev/core2_v1.0.0_JS/buRRRn/core2.js
| Line: 21)

the ECMAScript host where this code has been tested that you can see
listed here
http://www.burrrn.com/projects/core2.html
do not yeld such a warning

in brief, if the host where you're running the code is not included in the
tested hosts sure some warning could be yeld, it just a matter of adding
those hosts to the test cycle.

The warning is there on all platforms and OSes since Gecko 1.0, if not
before.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;

charset=ISO-8859-1">

^^
<title>core2 Test</title>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2.js"
type="text/javascript"></script>
<script src="release/dev/core2_v1.0.0_JS/buRRRn/core2/_global.js"
type="text/javascript"></script>

stop here

that's why there is a DEV release and a LIB release

to save you trouble to include dozens of script files
you would be better using the library as 1 single file

<script src="release/lib/core2_v1.0.0_JS.js"
type="text/javascript"></script>

you can not just include part of the library, you have to include all the
files.

I call that an example of incompetent design, see below.

<script type="text/javascript">
var x, y, z;

function _onload()
{
trace( ToSource( 0 ) );
}
</script>
</head>

<body onload="_onload();">
<div id="TraceConsole"></div>
</body>
</html>

as you are including only parts of the core2 library
it surely does not work

core2 is about augmenting all the ECMAScript core objects,
this create a dependency on core2 itself,
it's all or nothing, you can not pick part of the core2 library.

This is a design choice, we stick to the objects we avoid global function,
it got its pros and cons, one of the pros is that it allow a lot of code
reuse,
one of the cons is that it force you to include all the files.

No, it does not force such if it was properly designed. When I use my
script libraries (JSX -- JavaScript eXtensions, as I call them) which also
augment native prototypes if necessary, I only have to use those I need for
the task and those that are required by dependencies. That is, e.g., if I
require features provided by types.js such as isArray(), I also need to
include object.js (since types.js uses Object.prototype.addProperties
augmented by the latter), unless it seems more efficient to copy only
one method's source; nothing more.

on

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051224
Debian/1.5.dfsg-3 Firefox/1.5 Mnenhy/0.7.3.0

ok, I can not test on Linux, but your case interest me
as the goal is to be able to run in any hosts and in particular any OS

I will add tests using Firefox v1.5 on windows
hoping that the windows version have a similar behaviour than the linux
version

this is an evolving project, the main part is stable (hence the versioning
1.0.0)

I would hardly call a version with a major (and admitted stupid) bug that
is not properly tested on the second widest distributed script engine
(SpiderMonkey, the JavaScript C Reference Implementation) stable or even
dared giving it a 1.0 major version.
but there still could have some bugs or glitch that can be improved.

When core2 v1.0.0 was released Firefox v1.5 was still in beta for exemple.

It is the same since the first SpiderMonkey release, neither Firefox 1.5
nor JavaScript 1.6 do anything new here. You are winding around your
incompetence regarding code design and release schedule:

and there is no occurence of the word `mm' in the rest of the files that
would declare that variable. Maybe you can explain what I did wrong.

except including just "_global.js" and "Object.js", you did nothing wrong

the "mm" local variable is a bug that I did not catch in time,
it will be solved for the core2 v1.0.1 release
[snip]

It also talks volumes that your HTML documentation of the project refers

to

prototype objects as "Classes". Why am I not surprised?

<URL:http://www.burrrn.com/documentation/core2/index/Classes.html>

So much for your understanding of the programming language(s) used.

[lame excuse]

And, as I expected, you blame other people for your incompetence.
PointedEars

Dec 30 '05 #32

zwetan

"Thomas 'PointedEars' Lahn" wrote:
[snip]

can you provide a scenario of what you would expect ?

like: I got this code, if I trace this reference of code I would expect
this result, not that result.
function x()
{
var y = 23, z;
}
x.foo = 42;

A solution returning a list of the variables declared in the local context
of x() should return a list with the elements `y' and `z' (and maybe a
representation of their assigned value). A solution returning a list of
`var' statements in the local context of x() should return a list with
the only element

var y = 23, z;

the natively, implemented in SpiderMonkey, "toSource" function don't do that

core2 "toSource" function try to have the same behaviour, no less, no more.

simpler goal but more efficient when you target a lot of different hosts

A solution returning the enumerable properties of the Function object `x'
refers to (short: x) should at least return `foo', but not `y' or `z',
because the latter ones are properties of the Variable Object created when
the method is called and the local context is entered, not properties of x.
some limitations:
- impossibility to trace member marked as "DontEnum"
It is possible to "trace" known properties that have the DontEnum flag.
My ObjectInspector[1] does a pretty good job at that.

no.
for exemple your "ObjectInspector", as it is, does not work in JSDB, Flash,
etc..

you could say you don't care about flash..ok
me I can say JSDB tool is based on the SpiderMonkey engine and fully
implement JavaScript 1.5
but as it is a command line tool it does not have access to a browser DOM
and on that environnment your inspector does not work

your "ObjectInspector" is heavyly dependant on the browser, the DOM etc..

core2 "toSource" is only dependant on the ECMAScript language,
not on the host implementing the language.

- no assignement of pointers to represent circular reference

I am not sure what you mean by that.

try that in JSDB: (www.jsdb.org)

js>var _global = this;
js>foobar = {};
[object Object]
js>foobar.test = _global;
[object global]
js>write( foobar.toSource() );
#2={test:#1={jsArguments:[], _global:#1#, foobar:#2#}}js>
js>

#1# is a pointer reference to _global
#2# is a pointer reference to foobar
It is possible to determine that a property value is a reference
to the property owner. My ObjectInspector can do that.

yes sure it can do that with browsers, what about the other ECMAScript hosts
?

have you ever heard of the concept of minimal common denominator ?

[1]
<URL:http://pointedears.de/scripts/test/O...y/latest/index
some differences:
- choice to not trace the body of Function object
So your library will _never_ be able to provide the solution the OP asked
for. In case you forgot: that was a list of all _`var' statements_.

I continued to talk with the OP and this is not what is looking for,
perharps he didn't expressed well in english using the word "statement"
instead of "state".

And afaik the OP is happy with the solution I have provided.

- choice to not implement toSource for REgEx object

That is /your/ decision (one that I would not follow) and /your/ problem.

yes, as it is your decision to support only the browsers,
me I decided to support more than that.

[...]
From "core2 v1.0.0.66 DEV for Browsers JavaScript",
release/dev/core2_v1.0.0_JS/buRRRn/core2/Object.js:269:

[snip]

notice that to have full tracing you need all core object "toSource"
implementation
not only the Object.prototype.toSource

this is implemented as a polymprophic behaviour,
each core object having its own implementation of toSource

if you don't include the Array, Boolean, etc. toSource implementation
sure it could not work as expected.

OMG. Are you telling me I have to include the whole Array.js for

| _global.ToSource = function( /*int*/ indent, /*String*/ indentor )
| {
| [...]
| var decal = "\n" + Array.initialize( indent, indentor ).join( "" );
| return( decal + "{" + decal + source.join( "," + decal ) + decal + "}"
| );
| }

which does nothing more than this?

you don't introspect an Array object as you introspect an Object object
well ... me I make a difference between the two (SpiderMonkey also make a
difference)

the goal here is not to make a debugger, just to have a portable function
with a coherent behaviour.

| Array.initialize = function( /*int*/ index, value )
| {
| if( index == null )
| {
| index = 0;
| }
| if( value === undefined )
^^^^^^^^^
| {
| value = null;
| }
| var arr, i;
| arr = [];
| for( i=0; i<index; i++ )
| {
| arr.push( value );
| }
| return arr;
| }

BTW: This will break in IE before version 5.5 (as it was introduced
in JScript 5.5). typeof value == "undefined" will not break in any
current or previous IE version that is still of any use (as the
operator was introduced in JScript 1.0, IE 3.0).

the "push" Array method does not exist in IE before version 5.5
so even if I was making the modification you're suggesting
it will still break with IE 5.0

there is a planned code branch to support older browsers
see http://live.burrrn.com/wiki/core2/patch

"patch is a special branch of the core2 library where the goal is to provide
implementation of some core objects methods for older ECMA-262 hosts.
For now the branch provide mostly patch for JScript v5.0, in case you want
to target Internet Explorer v5.0 browsers."
So your statement in news:43**********************@news.wanadoo.fr

| core2 is also a library which focus on ECMAScript programming, not
| the DOM programming.

is of course utter nonsense as well. Not only because of referring to
"DOM programming", but because of referring to "ECMAScript programming";
ECMAScript is an _abstract_ language specification for language
implementations based on language features of JavaScript 1.1 and JScript
1.0. In the real world you have to deal with the implementations, mostly
and particularly those in HTML UA's script engines, that is to date,
JavaScript, JScript, the Opera implementation, and KJS. The Specification
can only provide guidance here, it does not tell exactly how things really
are. It is error-prone and potentially harmful to rely on it only.

you should meditate what's written in this thread:
http://groups.google.com/group/netsc...80311ce1?hl=en

"
That's what I meant in my other post about "standard library mechanism"
-- it's fine to embed JS (JScript, whatever) in a Java, .NET, or other
world and use that world's standard packages. But people writing
portable JS, esp. for a common interoperable platform like the browser
or Linux, want a set of standard packages that are named and work the
same everywhere.
JS has lacked this for too long, being in the browser, or in the shadow
of a larger system of reusable packages such as a JVM. Nothing wrong
with Rhino, mind you -- but something's missing from JS-the-language.

"

core2 focus on ECMAScript-the-language and have the goal to produce a
portable
"standard library mecanism" that work the same everywhere.

[snip]
perharps you experiencing problems in indentation because
of the difference of CR/LF between Windows and Linux ?

No, it is not because of newline delimiters, as you should know and

probably already do know anyway. It is of you indenting

statement
{
block
}

instead of

statement
{
block
}

it's what I'm saying, your comment about my style of indentation is
irrelevant

and the like. You will find little support for the former indentation style here or elsewhere (including JavaScript source code for Gecko) because it
is harder to recognize and therefore harder to maintain than the latter or
something more like that.

you will also find this style of indentation

statement {
block }

who are you to say one way is better than another ?
[snip]
core2 v1.0.1 (planed for 2006/01/02) will solve all that
as a quick fix you can just replace "mm" local variable by "member".
I call that an example of incompetent release schedule.

that's your point of view.
[snip]
you can not just include part of the library, you have to include all the files.

I call that an example of incompetent design, see below.

that's your point of view. (but you sure like to apply the term
"incompetent" to me)
[snip]
No, it does not force such if it was properly designed. When I use my
script libraries (JSX -- JavaScript eXtensions, as I call them) which also
augment native prototypes if necessary, I only have to use those I need for the task and those that are required by dependencies. That is, e.g., if I
require features provided by types.js such as isArray(), I also need to
include object.js (since types.js uses Object.prototype.addProperties
augmented by the latter), unless it seems more efficient to copy only
one method's source; nothing more.

that's your way of doing and again I don't think you detain an universal
way of doing that everybody should use.

To efficiently use your lib people have to know
where are the dependencies, me I prefered to provide a library
where people don't even have to think where are the dependencies,
just 1 file to include, done.
[snip]

this is an evolving project, the main part is stable (hence the versioning 1.0.0)

I would hardly call a version with a major (and admitted stupid) bug that
is not properly tested on the second widest distributed script engine
(SpiderMonkey, the JavaScript C Reference Implementation) stable or even
dared giving it a 1.0 major version.

this major bug only apply to ToSource as a global function
it does not break or block all the other functionalities implemented
elsewhere
like String object methods, Array object methods, etc..

you are surely very skilled to diminish the work of others...

but there still could have some bugs or glitch that can be improved.

When core2 v1.0.0 was released Firefox v1.5 was still in beta for
exemple.
It is the same since the first SpiderMonkey release, neither Firefox 1.5
nor JavaScript 1.6 do anything new here. You are winding around your
incompetence regarding code design and release schedule:

yeah yeah yeah you do really like to call me "incompetent"

here what I already told you

| I didn't tested with FireFox v1.5 yet
|
| And as soon as i will test it for this particular host
| I will be able to valid or invalid your comment.
|
| I believe in unit tests not in biased individual with an agenda.
[snip]
And, as I expected, you blame other people for your incompetence.

no I don't do that, you're saying that.
after it's just a matter to know if what you are saying is relevant or total
bullshit...

next time I will run a word count on "incompetence" and "incompetent" :D

it's really hard to take seriously all what you're saying when
more than half of it is basic trolling
http://en.wikipedia.org/wiki/Internet_troll

zwetan

Dec 30 '05 #33

Thomas 'PointedEars' Lahn

zwetan wrote:

"Thomas 'PointedEars' Lahn" wrote:
> can you provide a scenario of what you would expect ?
>
> like: I got this code, if I trace this reference of code I would expect
> this result, not that result.
function x()
{
var y = 23, z;
}
x.foo = 42;

A solution returning a list of the variables declared in the local
context of x() should return a list with the elements `y' and `z' (and
maybe a
representation of their assigned value). A solution returning a list of
`var' statements in the local context of x() should return a list with
the only element

var y = 23, z;

the natively, implemented in SpiderMonkey, "toSource" function don't do
that

x.toSource() does return the source code of the function x().
core2 "toSource" function try to have the same behaviour, no less, no
more.
It is entirely possible to parse the return value of toSource() for
VariableStatements. However, it is not possible to emulate toSource()
so that it returns the same as the native method does, because that
user-defined method cannot differentiate between declared variables and
non-variable properties of the variable object referred to by `this'.
simpler goal but more efficient when you target a lot of different hosts
Non sequitur.

A solution returning the enumerable properties of the Function object `x'
refers to (short: x) should at least return `foo', but not `y' or `z',
because the latter ones are properties of the Variable Object created
when the method is called and the local context is entered, not
properties of

x.
> some limitations:
> - impossibility to trace member marked as "DontEnum"

It is possible to "trace" known properties that have the DontEnum flag.
My ObjectInspector[1] does a pretty good job at that.

no.

Yes it does.
for exemple your "ObjectInspector", as it is, does not work in JSDB,
Flash, etc..
My ObjectInspector uses means defined in the ECMASCript Language
Specification and supported by known conforming implementations to
determine if an object has the _known_ property. (If you would have
cared to look into the source code, you would have known.) We are
not talking about the (HTML) front end, of course.
core2 "toSource" is only dependant on the ECMAScript language,
not on the host implementing the language.
You have still not understood that ECMAScript is an _abstract_
language specification that _requires_ a real-world implementation
and a host environment.

> - no assignement of pointers to represent circular reference

I am not sure what you mean by that.

try that in JSDB: (www.jsdb.org)

js>var _global = this;
js>foobar = {};
[object Object]
js>foobar.test = _global;
[object global]
js>write( foobar.toSource() );
#2={test:#1={jsArguments:[], _global:#1#, foobar:#2#}}js>
js>

#1# is a pointer reference to _global
#2# is a pointer reference to foobar

There are no pointers in ECMAScript implementations. The correct term
is (object) reference, and the meaning is different from "pointer".

What is your point anyway?

It is possible to determine that a property value is a reference
to the property owner. My ObjectInspector can do that.

yes sure it can do that with browsers, what about the other ECMAScript
hosts ?

Of course it is possible there, too.

var o = {};
o.foo = o;

if (o.foo === o)
{
// o.foo is a reference to its owner
}
have you ever heard of the concept of minimal common denominator ?
You have no clue of what you are talking about. You claim
to have understood what you are doing, but you have not.
[snipped more winding around and more nonsense]

You really cannot be helped.
PointedEars

Dec 31 '05 #34

Thierry Loiseau

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

zwetan wrote:
"Thomas 'PointedEars' Lahn" wrote:

I'm sorry ; I don't know how to descript your discuss, because in
english, because in "profonde" JS

:-/

Dec 31 '05 #35

zwetan

You really cannot be helped.

you are just a troll and now are blacklisted

get a life kiddo

zwetan

Dec 31 '05 #36

How to list the statement of all var ?

Similar topics