zwetan wrote:
[color=blue]
> "Thomas 'PointedEars' Lahn" wrote:[color=green]
>> zwetan wrote:
>> [...]
>> Probably you meant to say "There are no associative Arrays in[/color]
> JS/ECMAScript.[/color]
^^^^
Please get your NetNews posting software repaired:
<URL:http://insideoe.com/>
[repaired broken quotes][color=blue][color=green]
>> What is achieved with associative arrays in other languages, is provided
>> by properties of objects and property accessors here."[/color]
>
> 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,[/color]
This is on-topic as long it is about JS/ECMAScript.
[color=blue]
> 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 ?[/color]
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.
[color=blue]
> 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 ?[/color]
Because it has already been discussed at great length here before.
[color=blue]
> [...][color=green][color=darkred]
>> > in FF for ex:[/color]
>> No, it will not always, unless toSource() is user-defined.[/color]
>
> "in FF" mean "in FireFox"...[/color]
It does not work this way in Firefox (1.5) without prototype augmentation,
or in JavaScript for that matter, and it never has.
[color=blue]
> you don't need to define the toSource method in FireFox afaik[/color]
True, there is native prototype.toSource() for several core objects but
it does returns something different than you suggest in all cases.
[color=blue]
> it's natively implemented in the SpiderMonkey engine.[/color]
Yes, but it does not do what you suggest.
[color=blue]
> (and please don't point that I don't provide the exact version of the
> engine)[/color]
It does not and has never worked this way in any SpiderMonkey version.
[color=blue][color=green][color=darkred]
>> > if you want the same functionality in any browser[/color]
>> You meant to say "with any script engine" but even that would not be
>> true.[/color]
>
> you know I just posted a comment to help someone,
> I can not really phrase all my comments to suit your taste.[/color]
Usage of exact terms are one important key to understanding.
[color=blue]
> I meant "any browser" as "any browser host", as "any browser host
> implementing ECMA-262 standard", [...][/color]
It would have been true if you wrote "any language that is an
ECMAScript _3_ implementation." What is a "browser host" anyway?
[color=blue]
> 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[/color]
Yes.
[color=blue]
> and so not being able to execute JavaScript ?[/color]
The question conveys a misconception about ECMAScript and JavaScript.
ECMAScript (3) !== JavaScript (1.5).
[color=blue][color=green][color=darkred]
>> > you can also use my
>> > core2 library
>> >
http://www.burrrn.com/projects/core2.html
>> >
>> > here an exemple
>> > ---------------
>> > <html>
>> > <body>
>> > <head>[/color]
>>
>> Invalid examples are worthless. <URL:http://validator.w3.org/>[/color]
>
> 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[/color]
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.
[color=blue]
> as I don't syntax check all my newsgroups post[/color]
I do not either. That is not the point.
[color=blue]
> 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[/color]
The rest of your markup is not Valid, too.
[color=blue]
> 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[/color]
/You/ _posted_ the example.
[color=blue]
> are we here to help someone solve a problem
> or to start a fight on what is worthless or not ?[/color]
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.
[color=blue][color=green][color=darkred]
>> > will trace in the DIV[/color]
>>
>> 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'.[/color]
>
> You see "tracing" in a different way that I see it and also in a different
> context.[/color]
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
...
}
};
[color=blue]
> core2 goal is to be able to run anywhere there is a compliant ECMA-262
> interpreter,[/color]
An implementation conforming to ECMAScript _Edition 3_.
[color=blue]
> [...][/color]
You are winding around the issue.
[color=blue][color=green]
>> I also see other examples of bad code style:
>> an undeclared variable just to call a function and then `delete' it,[/color]
>
> does this cause a bug ?[/color]
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'.
[color=blue][color=green]
>> bad indentation,[/color]
>
> did you realize that the LIB releases have indeed their indentation
> striped out
> (as uncessary empty lines and code comments)[/color]
No, but that is not the point. You should and could have stripped it
better then.
[color=blue]
> 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.[/color]
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.
| */
| }
[color=blue][color=green]
>> error-prone property inference and so on.[/color]
>
> [...]
> 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.[/color]
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.
[color=blue]
> [...]
> 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.[/color]
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.
[color=blue][color=green]
>> ___________
>> [1] See <URL:http://en.wikipedia.org/wiki/Trace>, Computing, which you[/color]
> often[color=green]
>> like to refer to on your Web site.[/color]
>
> indeed the first line I read is "The word trace has several meanings" :)[/color]
We are talking about applied computer science, do we not?
[color=blue]
> with a little advance I wish you an happy new year 2006 PointedEars
> live long and prosper[/color]
Thanks, you too.
PointedEars
