Hi all,
I've been working on implementing new binding resolver based on ast dom model
as a replacement for
DefaultBindingResolver that uses internal compiler data unavailable since we've
switched to esprima parser.
Since this work had been started in order to fix "Bug 489897 - Mark Occurrences
is not working on JavaScriptEd..."
I had to look into JavaEditor and I've noticed one thing which is not actually
obvious for me.
JavaSriptEditor preferences page for 'Mark Occurrences' has several check-boxes
for configuring what to mark:
'Functions' 'Constants' 'Local variables' 'Function exits' 'Targets of break
and continue statements'
JavaSriptEditor tries to find out what kind of symbol(variable, function, type)
is at cursor position then analyses
type binding and so on and so forth. I wonder if it all makes sense actually?
Look at the sample code at the end of
the message.
What is 'a' in function bar? Function or variable? What is 'c' in that
function? Function or variable?
What is the type of 'c' ? Number or function, What is the type of 'd' ?
Undefined or Object or Array or what?
What are 'l1' , 'l2' in function 'barr' What is 'x' at global scope?
I'm not criticizing. I just believe that dynamic nature of JS makes such
attempts to strongly rely on Type useless.
JS "type" of symbol is rather a Set of Probable 'types' and we can't tell
actually whether symbol is variable or
'function'. Perhaps we can say call site...
Nevertheless, it's another long story; I actually want to ask if it makes sense
to bother with all that complexities?
Wouldn't be better to just mark 'symbol occurrences'. It means marking symbol
declaration and symbol references
depending on scope? It seems more clear for me and besides it's cheaper/faster
from computation point of view.
I'm not that familiar with other JS editors/IDEs, so I can't tell what they do
in such case. Orion though just marks
'symbol occurrence' as far as I can see.
What do you think?
// ======= Here is sample code mentioned above =============
function foo (a,b) {
return a+b;
}
function bar(a, b, c, d) {
if (typeof (c) == 'function') {
return c(a,b);
} else if (typeof(a) == 'function'){
return {a: d.a, b: d[c], c: d["c"], d: a(b,c)};
}
}
function barr() {
var l1 = 10, l2 = 20;
l1: for(var i=1; i < 10; i++) {
l2: for(var j=1; j < 10; j++) {
if (j==5) {
break l1;
} else if ( j==6) {
continue l2;
}
}
}
return l1+l2;
}
barr();
var x = foo;
x = x(1,2);
console.log("x = "+x);
var v = foo(1,2);
var w = bar(3,4,foo)
var x = bar(5,6, function (a,b) {return a+b;});
var y = bar(7,8, (a,b) => a+b);
var z = bar((a,b) => a+b, 9, 10, {a:11, 10: 12, c: 13});
console.log("v = "+v);
console.log("w = "+w);
console.log("x = "+x);
console.log("y = "+y);
console.log("z = {"+z.a+","+z.b+","+z.c+","+z.d+"}");
--
Eugene Melekhov
_______________________________________________
wtp-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
