Community
Participate
Working Groups
Build Identifier: helios for ee developers In Rhino console I'm getting: "d:/eclipseHelios_workspace/test-js/utils/alerts.js", line 34: uncaught JavaScript runtime exception: ReferenceError: "level" is not defined. for a declaration like "level.one.prototype.a=1;" although it is not highlighted as an error in Eclipse Helios js editor. In the New and Noteworthy of WTP 3.2 JSDT, see section "Improved namespace support". "level" is called a "namespace" in this case. If i modify the file adding before that: "level = { one : function(){}};" then Rhino console does not issue an error anymore. Also, declaring "level" like "level = { };" would not be enough. "one" sould alse be declare in "level", or else i get "uncaught JavaScript runtime exception: TypeError: Cannot read property "prototype" from undefined" Should Javascript namespaces like "level" in this example be declared previously as objects? Should properties like "one" be also initialized to functions? Reproducible: Always Steps to Reproduce: 1. create a js script file with "level.one.prototype.a=1;" 2. load it in rhino console with load() command 3.
Syntactically it is not an error. Semantically as you're finding it is an error. The use of objects as something resembling namespaces is an idiom with no direct support in the language. So this means that you indeed really have to create the appropriate objects or else have them pre-declared in another script. At the level of a single JavaScript file we do not have the context to know if the variable as previously been declared and determine whether or not this assignment is an error. I'll still leave this bug open though as clearly using a runtime like Rhino we can find the problem so at some point we might be able to identify this sort of problem.
(In reply to comment #1) > Syntactically it is not an error. Semantically as you're finding it is an > error. The use of objects as something resembling namespaces is an idiom with > no direct support in the language. So this means that you indeed really have to > create the appropriate objects or else have them pre-declared in another > script. > At the level of a single JavaScript file we do not have the context to know if > the variable as previously been declared and determine whether or not this > assignment is an error. I'll still leave this bug open though as clearly using > a runtime like Rhino we can find the problem so at some point we might be able > to identify this sort of problem. Rhino already identifies this sort of pb. Doesn't it? You want to test with a "namespace"-like object initialisation in a previously loaded file? If the declaration of the "namespace"-like object is in the same file, it works, as i said. Also, browsers do not consider this a semmanticall error, right?
> Rhino already identifies this sort of pb. Doesn't it? You want to test with a > "namespace"-like object initialisation in a previously loaded file? We're not using Rhino for semantic validation we're using inferencing which is unlikely to catch this sort of problem. > If the declaration of the "namespace"-like object is in the same file, it > works, as i said. Yes, all that needs to happen is that namespace objects need to be created before the assignment. > Also, browsers do not consider this a semmanticall error, right? Yep it's an error unless the namespace object is pre-defined. Nothing special about Rhino here.
> Rhino already identifies this sort of pb. Doesn't it? You want to test with a > "namespace"-like object initialisation in a previously loaded file? > We're not using Rhino for semantic validation we're using inferencing which is > unlikely to catch this sort of problem. Actually...we should be able to catch this sort of problem.
(In reply to comment #1) > Syntactically it is not an error. Semantically as you're finding it is an > error. Yes, it's Rhino who finds this error: '... ReferenceError: "level" is not defined.' >I'll still leave this bug open though as clearly using > a runtime like Rhino we can find the problem so at some point we might be able > to identify this sort of problem. You already identify it, see above. If by "we" you include Rhino too :) Or do you mean make the js editor "find the problem" at script-editing validation time and before loading the script in Rhino? >Syntactically it is not an error. Semantically as you're finding it is an error. Ok, so you are planning to make the jsdt js editor underline it in red as a semantic problem, right?
The JSDT editor should mark this as an error using its own validation checking. Rhino has nothing to do with the JS editor. They are not connected at all.
