Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » Type Hierarchy features
| Type Hierarchy features [message #30642] |
Mon, 25 August 2008 22:14  |
Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Hi. I've been doing some more work on the DLTK-based D Eclipse IDE, and
I was trying to implement the Type Hierarchy View features, however I
couldn't get it to work correctly, and I'm not sure if it's due to an
error on my part, or due to some bugs in DLTK.
Has this feature been fully implemented in DLTK, or is it a
work-in-progress? I've seen some strange bugs which seem to come from
DLTK, like the same type having a certain hierarchy shown the first time
the view (or TH popup) is invoked, but having a different hierarchy the
second and subsequent times the view is invoked, even though no code has
been changed meanwhile!
If it's fully implemented, can you give an overview of how the Type
Hierarchy features work (both from a user-viewpoint, and from an IDE
plugin view-point)? How does DLTK determine the superclass elements,
given only the TypeInfo.superclasses String array in the
SourceElementParser? Is the Type Hierarchy feature able to correctly
identify all subtypes of the class under analysis?
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: Type Hierarchy features [message #30677 is a reply to message #30642] |
Mon, 25 August 2008 23:02  |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Bruno Medeiros wrote:
> Hi. I've been doing some more work on the DLTK-based D Eclipse IDE, and
> I was trying to implement the Type Hierarchy View features, however I
> couldn't get it to work correctly, and I'm not sure if it's due to an
> error on my part, or due to some bugs in DLTK.
>
> Has this feature been fully implemented in DLTK, or is it a
> work-in-progress? I've seen some strange bugs which seem to come from
> DLTK, like the same type having a certain hierarchy shown the first time
> the view (or TH popup) is invoked, but having a different hierarchy the
> second and subsequent times the view is invoked, even though no code has
> been changed meanwhile!
>
> If it's fully implemented, can you give an overview of how the Type
> Hierarchy features work (both from a user-viewpoint, and from an IDE
> plugin view-point)? How does DLTK determine the superclass elements,
> given only the TypeInfo.superclasses String array in the
> SourceElementParser? Is the Type Hierarchy feature able to correctly
> identify all subtypes of the class under analysis?
>
>
I forgot to mention, this happens with latest stable version:
S-1.0M1-200808150915
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: Type Hierarchy features [message #30713 is a reply to message #30642] |
Wed, 27 August 2008 01:40 |
 Alex Panchenko
Messages: 342
Registered: July 2009 |
Senior Member |
|
|
Hi Bruno,
Type hierarchy is supposed to be working, however there could be some
bugs or side effects after changing the related parts of the system.
From the user viewpoint is should work the same as in JDT. The super
classes are determined by the name - in the interpreter languages there
are no other ways to statically identify it, but if you have class with
the same name in different files then there is no simple choice.
I am going to review the type hierarchy on the next week.
After that I will post the message with more details, please stay tuned.
Regards,
Alex
Bruno Medeiros wrote:
> Hi. I've been doing some more work on the DLTK-based D Eclipse IDE, and
> I was trying to implement the Type Hierarchy View features, however I
> couldn't get it to work correctly, and I'm not sure if it's due to an
> error on my part, or due to some bugs in DLTK.
>
> Has this feature been fully implemented in DLTK, or is it a
> work-in-progress? I've seen some strange bugs which seem to come from
> DLTK, like the same type having a certain hierarchy shown the first time
> the view (or TH popup) is invoked, but having a different hierarchy the
> second and subsequent times the view is invoked, even though no code has
> been changed meanwhile!
>
> If it's fully implemented, can you give an overview of how the Type
> Hierarchy features work (both from a user-viewpoint, and from an IDE
> plugin view-point)? How does DLTK determine the superclass elements,
> given only the TypeInfo.superclasses String array in the
> SourceElementParser? Is the Type Hierarchy feature able to correctly
> identify all subtypes of the class under analysis?
|
|
|
| Re: Type Hierarchy features [message #30780 is a reply to message #30713] |
Thu, 28 August 2008 23:02 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Alex Panchenko wrote:
> Hi Bruno,
>
> Type hierarchy is supposed to be working, however there could be some
> bugs or side effects after changing the related parts of the system.
>
> From the user viewpoint is should work the same as in JDT. The super
> classes are determined by the name - in the interpreter languages there
> are no other ways to statically identify it, but if you have class with
> the same name in different files then there is no simple choice.
>
> I am going to review the type hierarchy on the next week.
> After that I will post the message with more details, please stay tuned.
>
> Regards,
> Alex
>
>
Thanks.
Also, for the record, I was interested in something indeed like JDT's
views, as D has the same inheritance model as Java: single inheritance +
multiple interfaces, and a common Object superclass for all classes.
In DLTK some of the differences I found (besides the odd bugs), where:
* In the supertype hierarchy, the list of supertypes is ordered
alphabetically. I would rather the order of supertypes given by the
SourceElementParser was respected, especially because I want to make
sure the class supertype always appears before the interface supertypes
(like JDT)
* In the subtype hierarchy, besides only some of the subtypes appearing,
the view also shows the supertype hierarchy (in the direction torwards
the root of the treeview, which is weird). In JDT, the subtype hierarchy
also shows some of the supertypes, but only the primary supertype (ie,
the parent class), so that you can form a single branch upwards in the
TreeViewer, instead of multiple upward branchs, which is weird (if I
make myself clear).
I'll stay tuned! :)
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
|
|
|
| Re: Type Hierarchy features [message #31137 is a reply to message #30780] |
Wed, 17 September 2008 13:54 |
Alex Panchenko
Messages: 342
Registered: July 2009 |
Senior Member |
|
|
Bruno Medeiros wrote:
> Alex Panchenko wrote:
>> Hi Bruno,
>>
>> Type hierarchy is supposed to be working, however there could be some
>> bugs or side effects after changing the related parts of the system.
>>
>> From the user viewpoint is should work the same as in JDT. The super
>> classes are determined by the name - in the interpreter languages
>> there are no other ways to statically identify it, but if you have
>> class with the same name in different files then there is no simple
>> choice.
>>
>> I am going to review the type hierarchy on the next week.
>> After that I will post the message with more details, please stay tuned.
>>
>> Regards,
>> Alex
>>
>>
>
> Thanks.
> Also, for the record, I was interested in something indeed like JDT's
> views, as D has the same inheritance model as Java: single inheritance +
> multiple interfaces, and a common Object superclass for all classes.
>
> In DLTK some of the differences I found (besides the odd bugs), where:
> * In the supertype hierarchy, the list of supertypes is ordered
> alphabetically. I would rather the order of supertypes given by the
> SourceElementParser was respected, especially because I want to make
> sure the class supertype always appears before the interface supertypes
> (like JDT)
> * In the subtype hierarchy, besides only some of the subtypes appearing,
> the view also shows the supertype hierarchy (in the direction torwards
> the root of the treeview, which is weird). In JDT, the subtype hierarchy
> also shows some of the supertypes, but only the primary supertype (ie,
> the parent class), so that you can form a single branch upwards in the
> TreeViewer, instead of multiple upward branchs, which is weird (if I
> make myself clear).
>
> I'll stay tuned! :)
I have fixed some bugs in DLTK type hierarchy implementation, now it
works correctly at least for Ruby and TCL.
Current DLTK infrastructure is designed for scripting languages that are
interpreted at runtime. In these languages it is not possible to
statically build the exact model - it depends on the files executed by
interpreter, so DLTK uses search by the super class name to find
possible parents.
D is a compilable language, so you should be able to calculate the exact
superclasses - so you may need enhancements to the DLTK to provide your
own implementations for some of the functionality.
When you are ready please file issues in bugzilla and attach patches to
them.
Regards,
Alex
|
|
|
| Re: Type Hierarchy features [message #32426 is a reply to message #31137] |
Thu, 02 October 2008 19:35 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros.gmail.com
Alex Panchenko wrote:
> Bruno Medeiros wrote:
>> Alex Panchenko wrote:
>>> Hi Bruno,
>>>
>>> Type hierarchy is supposed to be working, however there could be some
>>> bugs or side effects after changing the related parts of the system.
>>>
>>> From the user viewpoint is should work the same as in JDT. The super
>>> classes are determined by the name - in the interpreter languages
>>> there are no other ways to statically identify it, but if you have
>>> class with the same name in different files then there is no simple
>>> choice.
>>>
>>> I am going to review the type hierarchy on the next week.
>>> After that I will post the message with more details, please stay tuned.
>>>
>>> Regards,
>>> Alex
>>>
>>>
>>
>> Thanks.
>> Also, for the record, I was interested in something indeed like JDT's
>> views, as D has the same inheritance model as Java: single inheritance
>> + multiple interfaces, and a common Object superclass for all classes.
>>
>> In DLTK some of the differences I found (besides the odd bugs), where:
>> * In the supertype hierarchy, the list of supertypes is ordered
>> alphabetically. I would rather the order of supertypes given by the
>> SourceElementParser was respected, especially because I want to make
>> sure the class supertype always appears before the interface
>> supertypes (like JDT)
>> * In the subtype hierarchy, besides only some of the subtypes
>> appearing, the view also shows the supertype hierarchy (in the
>> direction torwards the root of the treeview, which is weird). In JDT,
>> the subtype hierarchy also shows some of the supertypes, but only the
>> primary supertype (ie, the parent class), so that you can form a
>> single branch upwards in the TreeViewer, instead of multiple upward
>> branchs, which is weird (if I make myself clear).
>>
>> I'll stay tuned! :)
>
> I have fixed some bugs in DLTK type hierarchy implementation, now it
> works correctly at least for Ruby and TCL.
>
I have tested this with the new DTLK version: R-0.95.1-200809201836
It looks better overall, but I still found some bugs:
The Type Hierarchy *View* seems broken as before: if I request a subtype
or supertype view for a given type, the first time appears correctly,
but the second time (with no changed code) the hierarchy appears empty
(with only the selected type appearing).
The Type Hierarchy *Popup* seems to work correctly if all the supertypes
or subtypes are in the same file. However, if some of the types are in a
different file, the same problem as the Hierarchy View happens: the
first view appears OK, but subsequent ones appear wrong (with only one
element). (subsequent views in the popup are achieved by pressing Ctrl-T
repeatedly)
> Current DLTK infrastructure is designed for scripting languages that are
> interpreted at runtime. In these languages it is not possible to
> statically build the exact model - it depends on the files executed by
> interpreter, so DLTK uses search by the super class name to find
> possible parents.
>
> D is a compilable language, so you should be able to calculate the exact
> superclasses - so you may need enhancements to the DLTK to provide your
> own implementations for some of the functionality.
>
> When you are ready please file issues in bugzilla and attach patches to
> them.
>
> Regards,
> Alex
I would like to do this, but I'm not sure I'll have the time. I'll try.
One thing I at least would like to implement, is to have the hierarchy
respect the order of supertypes I give in the SourceElementParser.
Hopefully that won't be too hard.
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
|
|
|
| Re: Type Hierarchy features [message #32565 is a reply to message #32426] |
Sat, 04 October 2008 04:16 |
Alex Panchenko
Messages: 342
Registered: July 2009 |
Senior Member |
|
|
Bruno,
The active development of DLTK is performed in the 1.0 version.
Recently M2 was released.
Only fixes for the critical bugs are backported to the 0.95.x versions.
I would recommend you to use 1.0 builds for development of your IDE.
Regards,
Alex
Bruno Medeiros wrote:
> Alex Panchenko wrote:
>> Bruno Medeiros wrote:
>>> Alex Panchenko wrote:
>>>> Hi Bruno,
>>>>
>>>> Type hierarchy is supposed to be working, however there could be
>>>> some bugs or side effects after changing the related parts of the
>>>> system.
>>>>
>>>> From the user viewpoint is should work the same as in JDT. The
>>>> super classes are determined by the name - in the interpreter
>>>> languages there are no other ways to statically identify it, but if
>>>> you have class with the same name in different files then there is
>>>> no simple choice.
>>>>
>>>> I am going to review the type hierarchy on the next week.
>>>> After that I will post the message with more details, please stay
>>>> tuned.
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>>
>>>
>>> Thanks.
>>> Also, for the record, I was interested in something indeed like JDT's
>>> views, as D has the same inheritance model as Java: single
>>> inheritance + multiple interfaces, and a common Object superclass for
>>> all classes.
>>>
>>> In DLTK some of the differences I found (besides the odd bugs), where:
>>> * In the supertype hierarchy, the list of supertypes is ordered
>>> alphabetically. I would rather the order of supertypes given by the
>>> SourceElementParser was respected, especially because I want to make
>>> sure the class supertype always appears before the interface
>>> supertypes (like JDT)
>>> * In the subtype hierarchy, besides only some of the subtypes
>>> appearing, the view also shows the supertype hierarchy (in the
>>> direction torwards the root of the treeview, which is weird). In JDT,
>>> the subtype hierarchy also shows some of the supertypes, but only the
>>> primary supertype (ie, the parent class), so that you can form a
>>> single branch upwards in the TreeViewer, instead of multiple upward
>>> branchs, which is weird (if I make myself clear).
>>>
>>> I'll stay tuned! :)
>>
>> I have fixed some bugs in DLTK type hierarchy implementation, now it
>> works correctly at least for Ruby and TCL.
>>
>
> I have tested this with the new DTLK version: R-0.95.1-200809201836
> It looks better overall, but I still found some bugs:
>
> The Type Hierarchy *View* seems broken as before: if I request a subtype
> or supertype view for a given type, the first time appears correctly,
> but the second time (with no changed code) the hierarchy appears empty
> (with only the selected type appearing).
>
> The Type Hierarchy *Popup* seems to work correctly if all the supertypes
> or subtypes are in the same file. However, if some of the types are in a
> different file, the same problem as the Hierarchy View happens: the
> first view appears OK, but subsequent ones appear wrong (with only one
> element). (subsequent views in the popup are achieved by pressing Ctrl-T
> repeatedly)
>
>
>> Current DLTK infrastructure is designed for scripting languages that
>> are interpreted at runtime. In these languages it is not possible to
>> statically build the exact model - it depends on the files executed by
>> interpreter, so DLTK uses search by the super class name to find
>> possible parents.
>>
>> D is a compilable language, so you should be able to calculate the
>> exact superclasses - so you may need enhancements to the DLTK to
>> provide your own implementations for some of the functionality.
>>
>> When you are ready please file issues in bugzilla and attach patches
>> to them.
>>
>> Regards,
>> Alex
>
> I would like to do this, but I'm not sure I'll have the time. I'll try.
> One thing I at least would like to implement, is to have the hierarchy
> respect the order of supertypes I give in the SourceElementParser.
> Hopefully that won't be too hard.
>
>
|
|
|
| Re: Type Hierarchy features [message #33163 is a reply to message #32565] |
Tue, 07 October 2008 14:25 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros.gmail.com
Alex Panchenko wrote:
> Bruno,
>
> The active development of DLTK is performed in the 1.0 version.
> Recently M2 was released.
>
> Only fixes for the critical bugs are backported to the 0.95.x versions.
>
> I would recommend you to use 1.0 builds for development of your IDE.
>
> Regards,
> Alex
>
Oops, I thought I was using the latest version.
I tried M2 and it looks fine, no more of the repeating bugs. As for the
contents of the hierarchy itself: the supertypes appear ok, but no
subtypes appear. I checked the code and this seems to be related to this
line in computeSubtypesFor():
List extenders = (List)
superTypeToExtender.get(focusType.getTypeQualifiedName(TWO_C OLONS)
which doesn't quite work since superTypeToExtender is built with a map
key that could be the type name without qualifications.
In any case, what I really would like to do is to provide my own hook to
resolve the types in the hierarchy, by taking advantage of the static
typing of my target language (like you mentioned before).
I noticed you already have a type, IFileHierarchyResolver, which can be
contributed trough an extension. That seems pretty useful, and I think
that if HierarchyResolver was generified through that contributed type
(IFileHierarchyResolver or similar), so that I could customize the methods:
HierarchyResolver.computeSubtypes(IType) and
HierarchyResolver.computeSupertypes(IType)
it would be quite sufficient to allow my target language to properly
resolve the types. What do you think of this solution?
(Also, is it really necessary to have another extension for this?
Perhaps the IFileHierarchyResolver could be contributed through an
existing extension, like as another method of the ISearchFactory extension)
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
|
|
|
Goto Forum:
Current Time: Fri Apr 19 15:55:57 GMT 2024
Powered by FUDForum. Page generated in 0.03003 seconds |
] 
Search
Help
Register
Login
Home
