Re: How to list the statement of all var ?


"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/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_.
>

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:43b21772$0$6655$8fcfb975@xxxxxxxxxxxxxxx
>
> | 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/netscape.public.mozilla.jseng/msg/6f72e70880311ce1?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
bull***...

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



.

Loading