RE: [Dltk-dev] Open method action for functional languages

["Roy Ganor" <roy@xxxxxxxx>]

Hi Alex, thanks for the quick reply!

Trying to reuse the existing type search logic to the method case is a
good idea, actually when starting this task I have used this
methodology. However there were few problems implementing it.

Creating a base class for type/method information is necessary since the
search functionality is different in these two cases (in the method case
we need to filter out class methods so it won't be appeared as a result)
also we need to rename method signatures to accept generic elements,
this base class should delegate the search functionality to the subclass
methods. Moreover since methods are checked in a SourceModule scope
there is no need for the information of the class case. The problem here
is that I got over-design for only two types of elements that need to
participate in this feature, reusing existing code is a good practice
but when generalizing classes for _only_ two cases (classes and methods)
was resulted in "spaghetti" code. Also refactoring (public) method names
(like getTypeInfos(), getFilteredTypeInfos(), etc.) follows an extensive
refactoring process and API changes that are not necessary in our case. 

About the formatter issue, the formatter is automatically set for DLTK
projects and still I get many formatter fixes, anyone has experienced
such a problem before? 

Anyway, a patch was submitted today that fixes few problems. 
Regards,
- Roy

-----Original Message-----
From: dltk-dev-bounces@xxxxxxxxxxx [mailto:dltk-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alexey Panchenko
Sent: Friday, July 04, 2008 4:35 AM
To: DLTK Developer Discussions
Subject: Re: [Dltk-dev] Open method action for functional languages

Hi Roy,

First there are some general tips:

A lot of changes in your code patch are just formatting changes. Please
use Eclipse built-in formatter. All team members should use the same
formatting style to avoid unnecessary commits to the repository. 

Another tip is to update your working copy before creating the patch. So
the patch will be made against current HEAD - that increases the chances
the patch could be applied. I remember I have changed
PreferenceConstants yesterday and your patch is made against older
version of that file.

And now back to the Open Method action:

The patch length is almost 6k of lines. That is a lot. There are some
new classes. Are all of them required? Is is possible to reuse the code
used for the Open Type dialog? e.g. the OpenMethodHistory - is it
possible to inherit from OpenTypeHistory and override some methods? Or
introduce some AbstractOpenHistory and inherit both from it? The same
questions should asked about other classes.

What do you think?

Thanks,
Alex

----- Original Message -----
From: "Roy Ganor" <roy@xxxxxxxx>
To: dltk-dev@xxxxxxxxxxx
Sent: Thursday, July 3, 2008 11:23:43 PM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] Open method action for functional languages





Hi all, 

One important feature for functional languages developers like TCL and
PHP is the Open Method action (equivalent to Open Type feature or as we
all know it - Ctrl+Shift+T). 

I have submitted a patch in Bugzilla https://bugs.eclipse.org/239470 for
this issue. It is basically a different action and dialog than open type
and doesn't affect anyone who does not bind a command to this action. 

_______________________ 
Roy Ganor 






_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev