ExpressionVisitor and specific Javascript constructs

[Miquel Sabaté]

Hi there,

The Ruby guy here stepping in :) In Ruby you can do exactly the same thing:

a = def foo
  b = 'string'
  b
end

This is *weird* but it's doable :) In my case, kdev-ruby says that a is of
type String, which is correct. This is working in a local branch in which
I'm working right now and that I haven't pushed to master yet, but I think
that this example works in my master branch as well. So, maybe you might
want to take a look at how this situation is handled in kdev-ruby ;-) This
is the first thing that it's done in the
DeclarationBuilder::visitAssignStatement method. Basically, for each node
in the right side of the assignment we visit it through
DeclarationBuilderBase and then it's visited by the ExpressionVisitor. I'm
sure that this can be further optimized but right now I'm just making sure
that everything works. I hope that this helps :)

Greetings,
Miquel


2014-04-09 12:40 GMT+02:00 Sven Brauch <svenbrauch at googlemail.com>:

> Hi!
>
> On Wednesday 09 April 2014 11:44:33 Denis Steckelmacher wrote:
> > var a = function() {
> >      var b = 5;
> >      return b;
> > }
> >
> > This snippet exposes three areas where ExpressionVisitor has
> > difficulties to find the type of expressions:
> Indeed, you're right. I didn't think about that. That will be ugly to
> handle
> if you want to visit the function as an expression, as you already said.
>
> Thinking about it, Python has the same problem and solves it by simply not
> supporting it. That's not a problem there though, since this syntax can
> only
> be used for functions which only have one statement in their body, and it's
> discouraged to assign those to a name so effectively nobody is doing it.
> In JS
> this is obviously different. :(
>
> Your previous solution seems better suited for this particular case, but
> you
> lose the flexibility to determine the type of an expression outside of the
> builders (e.g. for completion) entirely ... so I am unsure how you would do
> that in the completion context then (assume you want to do completion on
> foo.bar[3].x.<cursor>, if you can't just throw that expression into
> something
> you are using in the analyzer anyways, it will either need a lot of
> duplicated
> functionality or will just not work).
>
> I see two other solutions:
>  1) simply make the declarationbuilder recognize this particular construct
> and
> treat it like function a() { ... }. That's a rather simple solution but
> it's
> not very future-proof, unfortunately, since there are other similar cases
> with
> the same problem most likely. Still, maybe this is what we should do for
> now
> -- it's simple and probably catches almost all cases.
>  2) this one I'm not sure about if it would work and it also sounds quite
> adventurous: You could in general build function contexts in the expression
> visitor. The openContext() method is not needed to instantiate contexts;
> you
> can create a DUContext* yourself, and then return it and open it from the
> context builder to merge it with the surrounding code. As said, I don't
> know
> if this would work and whether it would be ugly or not. It's probably not a
> good idea.
>
> Aleix, do you have any bright ideas regarding this?
>
> Greetings!
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140409/085d8a09/attachment.html>