Open declaration extension point

[frerich]

This extension point permits providing additional algorithms for
implementing the 'Open Declaration' functionality such that it works not
only for packages and subs.

The AbstractOpenDeclaration class has package-visibility and exposes a
bit more functionality than I'd like, so I decided to introduce anew
IOpenDeclarationHandler interface and expect extensions to implement
that. A ContributedOpenDeclarationHandler action wraps this interface
and forwards all calls.

[otrosien]

@frerich very interesting PRs. Can you elaborate on the background, is there a ticket, feature request or specification you followed somewhere?

[frerich]

@otrosien Indeed, there were multiple feature requests motivating these PRs. Our product (which comes with an IDE for which EPIC serves as the Perl editor), features custom Perl APIs which can be used to include external files (see #38). In some cases, those external files define an 'object repository' establishing a set of 'object names' referencing controls in a GUI. The script looks much like this (ObjectName is another API offered by our product):

our $gui = {};

$gui->{item_views_mainwindow} = ObjectName->new({"type" => "MainWindow", "windowTitle" => "Item Views"});
$gui->{item_views_qlistview}  = ObjectName->new({"type" => "QListView", "window" => $gui->{item_views_mainwindow}});

To recognize terms like $gui->{item_views_mainwindow} as identifiers, it appeared to be necessary to extend the tokenizer (see #39) - in our extension, we maintain a list of seen identifiers following the format $gui->{...}. In order to be able to jump to these definitions by considering our list of identifiers, we the need to be able to hook into the 'Open Declaration' functionality, which is what this PR is about.

[otrosien]

@jploski what do you think about the changes? I can't judge really because I'm not too deep into the code really.

[jploski]

I really have mixed feelings about this - these contributed extensions seem quite specific and are not well documented (in fact, there are "document me" placeholders in their manifests).

Introducing a couple extension points (of which EPIC doesn't have any as of yet) in lieu of a well thought-out and carefully specified API for third parties could be a wrong move. And it's a long-term commitment to maintain, as we cannot change once published APIs frivolously.

I understand the purpose of these extensions in context of the third-party product, but maybe they are best kept as a product-specific patch rather than integrated in the public code base. Either that, or they would have to be generalized (e.g. EPIC should also use its own Open Declaration extension by providing a default implementation) and documented so that the contract which needs to be upheld is clear to both EPIC developers and third parties.