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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/28/2008 09:36 AM Please respond to "General discussion of project-wide or architectural issues." <[email protected]> To "General discussion of project-wide or architectural issues." <[email protected]> cc Subject 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 ObjectLiterals. 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" type. Best Regards, Matthias Kempka -- Dipl.-Inform. Matthias Kempka Innoopract Informationssysteme GmbH [EMAIL PROTECTED] 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 information: 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 [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
