JavaScript plugin

[Sven Brauch]

How is the handling of "this" a problem? You can just obtain its type
from the context it's being used in; if in doubt, create an invisible
declaration when a new function context is opened. That shouldn't be
an issue, should it?
I think that prototypes should be fine, too. You can use the work we
did on this for python some time ago, it's in kdevplatform -- back
then, we found a working solution for declaring class variables
outside the class context. That's basically the same as prototypes
(except for a few static / non-static differences, which won't matter
much to kdevelop), as far as I understood the concept.

Really, I think you can build most of javascript by wildly combining
python and php, so I think you should be fine with a few minor
adjustments to the API, as both languages work well with it. I
wouldn't worry about that, it's probably going to work without
problems, and if not, it can be adjusted.

Cheers

Am 18. April 2012 17:43 schrieb Milian Wolff <mail at milianw.de>:
> On Wednesday 18 April 2012 08:41:08 Tatsh wrote:
>> Thanks for the help. I will be looking more at the current plugins then for
>> help on building mine.
>
> See below.
>
> <snip>
>
>> > Sounds good. One big task though might be to get the JS-specific scoping
>> > right. Not sure whether that might require special changes in our
>> > KDevplatform
>> > code since we so far mostly follow the "usual" scoping rules that apply to
>> > C-
>> > like languages but also work fine for Ruby and Python so far afaiks. But
>> > as
>> > far as I know, JS is pretty different in that regard.
>>
>> I don't know if you have implemented any support for PHP's closures, but
>> that also changes scope in a somewhat similar way. The only difference is
>> that PHP requires the use() construct to inject variables from the
>> outer-scope into the closure (and I think still requires global keyword to
>> get global variables). I think if any changes need to be made to KDevelop,
>> it would be effective for both JavaScript and PHP. It might even be helpful
>> in two other cases: gnu99 C where a closure-like functionality exists, and
>> closures in C/Objective-C/C++ (^ returntype (arg1, arg2) { /* body */ }
>> syntax (also known as blocks)).
>
> If that is all that's required, then yeah no changes are required b/c the
> above is easily handled via context-imports, e.g.:
>
> BEGIN CONTEXT A
>
> BEGIN CONTEXT B # closure e.g.
> IMPORT CONTEXT A
> # now everything visible in A is also visible in B
> END CONTEXT B
>
> END CONTEXT A
>
> I was assuming that JavaScript has more differences than that... Thinking
> about it, one thing that comes to mind is esp. the handling of "this". E.g.:
>
> var foo = someObj;
> foo.bar = function() {
>  // afaiks, this == foo here, or at least you can
>  // call this.bar and that is the same as foo.bar
> }
>
> And what about prototypes? :) We'll have to see how our architecture supports
> this, but we can patch it as we need to add support for anything you need.
>
> Anyhow, I think the first hurdle will be to get a proper parser ready. Once we
> have that, the rest shouldn't be too hard. So... create a git repo somewhere
> and start playing around. Once you found a feasible solution to create an AST
> from any *.js file, tell us and we can continue with the actual integration
> into a KDevelop language plugin. Imo you shouldn't worry too much about the
> existing language plugins right now.
>
> Cheers
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>