:
[snip]
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]
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.
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.
Yes, but it does not do what you suggest.
Yes It does you just didn't pay attention to what I suggest.
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]
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]
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
/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
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]
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...
avoid falacious arguments like that, it start to really be boring to read
you
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 ?
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