[news.eclipse.technology.dltk] Re: type hierarchy and code completion

["Chuck Doucette" <cdoucette@xxxxxxxxxxx>]

Thanks very much for your response.

I am currently casting: org.eclipse.dltk.compiler.env.ISourceModule as 
org.eclipse.dltk.internal.core.SourceModule since it also implements
org.eclipse.dltk.core.ISourceModule.

I need the latter type of ISourceModule interface in order to call 
SourceParserUtil.getModuleDeclaration.
The information I capture in my AST tree (and some associated structures) is 
used to implement my complete method rather than depending solely on the 
internal structure model which your example used to implement completion.

I wasn't sure how to implement import (as in Java). You have given me some 
ideas on how to do that.
I thought maybe mixin was involved which is why I asked about it. 
Apparently, it is not, but thanks for providing insight into it anyhow.

Chuck

"Andrei Sobolev" <haiodo@xxxxxxxxx> wrote in message 
news:g34s7g$ggg$1@xxxxxxxxxxxxxxxxxxxx
> Hi Chuck,
>
> AST tree and Structure model are two different models.
> AST is used to represent language internal strucures. Also AST are used to 
> do completion, selection etc.
>
> Structure model are used to represent only top level elements.
> This model represent projects, folders, files, classes, methods, field.
>
> Structure model are fixed and could not be extended by DLTK users.
> Language implementor could map some langauge elements to structure model 
> elements.
> Using of structure model gives some free features like Script Explorer, 
> outline, basic search.
>
> Some time ago we thinked about a way to show custom content fromd  all 
> generic DLTK views.
> Then will be possibly to display any kind of information.
>
> >I noticed that IType declares two codeComplete methods.
> >Those methods are implemented as dummy/no-op methods.
> This is JDT lagacy code, which is not realy used from anythere in DLTK.
>
> How to get AST from ICompletionEngine.complete()
> Original idea is to parse content with some advanced completion parser and 
> build some completion model.
> For example in Tcl we use Tcl AST tree but with some additional 
> processing, required for completion only.
>
> Two ISourceModule interfaces are also JDT legacy.
> JDT guys use similar class then they need completion for some code parts, 
> then no real ISourceModule are exists.
> In DLTK we also could use this classes in same context, but not do it yet.
> For example completion from wizards, breakpoint configuration view, etc.
>
> >b)    How does one make use of declarations from another module, i.e. 
> >Java import?
> You could obtain ISourceModule from search, or using some other way. For 
> example for python it will be eacy to get current ISourceModule
> parent and check for imported module name. etc.
>
> For  examples of how to use search please look to SearchTests class from 
> org.eclipse.dltk.tcl.core.tests project,
> and AbstractDLTKSearchTests class from org.eclipse.dltk.core.tests 
> project.
>
> Mixins:
> Some of scripting lanuages could have declarations from more then one 
> file.
> For example Tcl namespace could be declared from any set of files.
> Same thing is for Ruby classes, modules.
>
> Example:
> file1.rb:
> class MyClass
> def myMethod()
> end
> end
>
> file2.rb:
> class MyClass
> def myMethod2()
> end
> end
> In runtime Ruby will see both methods.
>
> Mixin model is intended to handle search in such langauges.
> Mixin model in two words:
> 1) From Script Builder for each type, method, field we report special 
> keys.
> Key represent path to element decoded as string, and could contain 
> subkeys.
> Example of keys for previous Ruby code:
>
> file1.rb:
> MyClass
> MyClass{myMethod
>
> file2.rb:
> MyClass{
> MyClass{myMethod2
>
> In this example MyClass{myMethod2 is subkey for MyClass
>
> 2) MixinModel user could ask for elements by key. Mixin will search for 
> all subkeys, and build tree of elements.
> For example if we ask for MyClass we wil recieve easy way to iterate all 
> it's children.
> Also language mixin parser could report some object instances, and we 
> could do correct completion, selection, without additional searchs.
>
> Best regards,
> Andrei Sobolev.