JavaScript plugin

[Tatsh]

On Wednesday, 18 April 2012, Sven Brauch wrote:

> 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?
>

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.

/**
 * @constructor
 */
var foo = function () {
  var eventHandler = function (event) {
    // this context will be the Element but the compiler doesn't care that
addEventListener is called below
    this.className = 'a';
    event.preventDefault(); // warning also because it has no idea of the
type of 'event'
  };
  someElementRef.addEventListener('click', eventHandler, false);
};

'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:

/**
 * @this {Element}
 */

The reason why it needs no help with the type of 'event' is because of the
annotations on Element.prototype.addEventListener:

/**
 * @param {string} eventName
 * @param {EventHandler|function(Event)} fn
 * @param {boolean} useHandle
 */
Element.prototype.addEventListener = function (eventName, fn, useHandle);


> 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.
>

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).

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:

"use strict";

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.

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):
https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words


> 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<javascript:;>
> >:
> > 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 <javascript:;>
> > http://milianw.de
> >
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org <javascript:;>
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> >
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org <javascript:;>
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120418/96956edd/attachment.html>