<br>On Wednesday, 18 April 2012, Sven Brauch wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How is the handling of "this" a problem? You can just obtain its type<br>
from the context it's being used in; if in doubt, create an invisible<br>
declaration when a new function context is opened. That shouldn't be<br>
an issue, should it?<br></blockquote><div><br></div><div>Actually the reason I mention it is because Closure Compiler can be 'dumb' at times regarding 'this' and context (intentional maybe but I think it's to do with the difficulty of resolving 'this' and keeping the compiler fast). Here's an example it cannot handle on its own and will give a warning unless an annotation is added.</div>
<div><br></div><div>/**</div><div> * @constructor</div><div> */</div><div>var foo = function () {</div><div> var eventHandler = function (event) {</div><div> // this context will be the Element but the compiler doesn't care that addEventListener is called below</div>
<div> this.className = 'a';</div><div> event.preventDefault(); // warning also because it has no idea of the type of 'event'</div><div> };</div><div> someElementRef.addEventListener('click', eventHandler, false);</div>
<div>};</div><div><br></div><div>'new foo();' will result in a warning that property className is not defined on 'foo'. The way to fix this is to add an @this annotation above:</div><div><br></div><div>/**</div>
<div> * @this {Element}</div><div> */</div><div><br></div><div>The reason why it needs no help with the type of 'event' is because of the annotations on Element.prototype.addEventListener:</div><div><br></div><div>
/**</div><div> * @param {string} eventName</div><div> * @param {EventHandler|function(Event)} fn</div><div> * @param {boolean} useHandle</div><div> */</div><div>Element.prototype.addEventListener = function (eventName, fn, useHandle);</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that prototypes should be fine, too. You can use the work we<br>
did on this for python some time ago, it's in kdevplatform -- back<br>
then, we found a working solution for declaring class variables<br>
outside the class context. That's basically the same as prototypes<br>
(except for a few static / non-static differences, which won't matter<br>
much to kdevelop), as far as I understood the concept.<br></blockquote><div><br></div><div>The only difference should be regarding static methods, where at least in ECMA 3, there is no 'self' keyword like in PHP (self is also not reserved in ECMA3; I believe it is in EMCA5 strict mode). You simply use the object name or you can also use the 'this' keyword in that method even if the original object is not a constructor function, but it is generally discouraged (at least with Closure Compiler).</div>
<div><br></div>Also is there such a thing in the platform to detect strict mode from code? It's very similar to Perl in JavaScript, however it's nothing but a string and is an exceptional language construct:<br><br>
"use strict";<div><br></div><div>I would think much like a mode line this would have to be in the very first 10 lines of any file that wants to use strict mode (although I am not sure on the standard). Having this line present could change rules on how the parser works and what errors/warnings it will give.</div>
<div><br></div><div>Just a note on reserved words that should be warned about in all modes if they are used as identifiers (Closure Compiler does warn about the 'future use' ones):</div><div><a href="https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words">https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words</a><br>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Really, I think you can build most of javascript by wildly combining<br>
python and php, so I think you should be fine with a few minor<br>
adjustments to the API, as both languages work well with it. I<br>
wouldn't worry about that, it's probably going to work without<br>
problems, and if not, it can be adjusted.<br>
<br>
Cheers<br>
<br>
Am 18. April 2012 17:43 schrieb Milian Wolff <<a href="javascript:;" onclick="_e(event, 'cvml', 'mail@milianw.de')">mail@milianw.de</a>>:<br>
> On Wednesday 18 April 2012 08:41:08 Tatsh wrote:<br>
>> Thanks for the help. I will be looking more at the current plugins then for<br>
>> help on building mine.<br>
><br>
> See below.<br>
><br>
> <snip><br>
><br>
>> > Sounds good. One big task though might be to get the JS-specific scoping<br>
>> > right. Not sure whether that might require special changes in our<br>
>> > KDevplatform<br>
>> > code since we so far mostly follow the "usual" scoping rules that apply to<br>
>> > C-<br>
>> > like languages but also work fine for Ruby and Python so far afaiks. But<br>
>> > as<br>
>> > far as I know, JS is pretty different in that regard.<br>
>><br>
>> I don't know if you have implemented any support for PHP's closures, but<br>
>> that also changes scope in a somewhat similar way. The only difference is<br>
>> that PHP requires the use() construct to inject variables from the<br>
>> outer-scope into the closure (and I think still requires global keyword to<br>
>> get global variables). I think if any changes need to be made to KDevelop,<br>
>> it would be effective for both JavaScript and PHP. It might even be helpful<br>
>> in two other cases: gnu99 C where a closure-like functionality exists, and<br>
>> closures in C/Objective-C/C++ (^ returntype (arg1, arg2) { /* body */ }<br>
>> syntax (also known as blocks)).<br>
><br>
> If that is all that's required, then yeah no changes are required b/c the<br>
> above is easily handled via context-imports, e.g.:<br>
><br>
> BEGIN CONTEXT A<br>
><br>
> BEGIN CONTEXT B # closure e.g.<br>
> IMPORT CONTEXT A<br>
> # now everything visible in A is also visible in B<br>
> END CONTEXT B<br>
><br>
> END CONTEXT A<br>
><br>
> I was assuming that JavaScript has more differences than that... Thinking<br>
> about it, one thing that comes to mind is esp. the handling of "this". E.g.:<br>
><br>
> var foo = someObj;<br>
> foo.bar = function() {<br>
> // afaiks, this == foo here, or at least you can<br>
> // call this.bar and that is the same as foo.bar<br>
> } </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> And what about prototypes? :) We'll have to see how our architecture supports<br>
> this, but we can patch it as we need to add support for anything you need.<br>
><br>
> Anyhow, I think the first hurdle will be to get a proper parser ready. Once we<br>
> have that, the rest shouldn't be too hard. So... create a git repo somewhere<br>
> and start playing around. Once you found a feasible solution to create an AST<br>
> from any *.js file, tell us and we can continue with the actual integration<br>
> into a KDevelop language plugin. Imo you shouldn't worry too much about the<br>
> existing language plugins right now.<br>
><br>
> Cheers<br>
> --<br>
> Milian Wolff<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'mail@milianw.de')">mail@milianw.de</a><br>
> <a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
><br>
> --<br>
> KDevelop-devel mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'KDevelop-devel@kdevelop.org')">KDevelop-devel@kdevelop.org</a><br>
> <a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
><br>
<br>
--<br>
KDevelop-devel mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'KDevelop-devel@kdevelop.org')">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</blockquote></div>