Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT inference: type of "this"

I have added a "public Object userData", so you can do what you want to with it.  
I suspect there are other problems involved if your inference engine is not being called.

Phil Berkland
IBM Software Group Emerging Technologies

Matthias Kempka <mkempka@xxxxxxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/28/2008 09:36 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Re: [wtp-dev] JSDT inference: type of "this"

On Apr 8, 2008, at 4:56 PM, Phil Berkland wrote:
> The default InferenceEngine will create an anonymous type when is  
> sees a Object Literal.
> Assuming that you have override handleFunctionCall() in you  
> inferengine to process the "qx.Class.define", in that code
> you would "drill down" to that object initializer and call  
> "traverse()" in its field initializers, thus bypassing the default  
> handling of visit(IObjectInitializer).
> The handleFunctionCall() should return false, so the InferEngine  
> does not visit the children of the function call .

I've tried this now. Unsuccessful, so far.

I made certain that visit(IObjectLiteral) in my inferencer is not  
called. While debugging, I even throw Exceptions in the overridden  
method, to be sure that the call doesn't pass there unnoticed. But  
still the original problem exists: The inner object literal has an own  
anonymous type.

I went into debugging to see where it is created:
The anonymous InferredType object that is passed to my  
QooxdooInferEngine is not created by the QooxdooInferEngine. It is  
created by another instance of InferEngine (itself, no subclass). So I  
never get the chance to do something regarding the type creation for  

However, it seemed awkward to me why I should reimplement the  
ASTVisitor aspect of the InferEngine anyway. Having an anonymous type  
as a placeholder during the type gathering is ok for me, and not  
uncommon from what I know about type inferencing in other languages. I  
just want to be able to tell it that it is the same type as "that one".
I didn't find anything in InferredType that suggests this  
functionality. So I set the superclass of the anonymous type to the  
known class. This works now for the functionality I intended right  
now, but is not formally correct and will come back and bite me as  
soon as I introduce visibility validation.

Do you think it would be reasonable to introduce a field in  
InferredType that allows me to say what it actually is? It would be  
close to the referenceClass, only not for array members but for "this"  

Best Regards,
Matthias Kempka

Dipl.-Inform. Matthias Kempka
Innoopract Informationssysteme GmbH
Tel:  0721 - 66 47 33 - 0
Fax: 0721 - 66 47 33 29
========================= Legal Disclaimer =====================
According to Section 80 of the German Corporation Act
Innoopract Informationssysteme GmbH must indicate the following  
Address: Stephanienstrasse 20, 76133 Karlsruhe Germany
General Manager: Jochen Krause, Eric von der Heyden
Registered Office: Karlsruhe, Commercial Register Karlsruhe HRB 7883

wtp-dev mailing list

Back to the top