hyperlinks

jgangemi wrote on Wed Nov 15 22:48:21 CET 2006:

are you aware of any limitations that would prevent hyperlink functionality
from working on the following:

package Foo;
use base qw(Bar);

....

1;

i'd like to be able to mouse over Bar, holding down the command key, and
click on it to open it's declaration.  there are actually a bunch of other
locations in code that i'd like to see this work for, ie:

foreach (@{$self->blah()})
{
  ...
}

something tells me from the way the code is "colored" (syntax highlighting)
that this issue lies in the parser, so it's a matter of whether or not it
can be addressed.

jploski wrote on Wed Nov 15 23:06:58 CET 2006:

The current implementation only considers partitions with a certain content
type (the "default" content type) as candidates for hyperlinks. My intent
for this restriction was to avoid converting arbitrary stuff such as operators
into hyperlinks. An unwanted side effect is that words which are subroutine
names enclosed in literals (as apparent in your qw example), are not considered
at all. This is not any inherent big limitation, just a flaw in the current
implementation which should be easily fixed (at the cost of possibly hyperlinking
irrelevant words in literals, but it does not really matter much).

Your other example with $self->blah() should already work as expected (with
blah becoming a hyperlink; of course we lack type information for $self,
so the location of blah is guessed).

jgangemi wrote on Wed Nov 15 23:44:18 CET 2006:

well - that irrelevant linking already occurs in this case: 

  $hash->{KEY}

as for the my other example, i have the following line of code:

foreach my $host (@{$self->extract_arrayref("node")})

i am unable to mouse over the "extract_arrayref" method and have it hyperlink
- i believe the dereferencing that is being done is what is causing the
hyperlink to break.

jgangemi wrote on Wed Nov 15 23:51:36 CET 2006:

also - could we integrate scanning through @ISA for hyperlinking in cases
where the method hanging off $self is in a parent class, or would that potentially
be a large performance hit?

jploski wrote on Thu Nov 16 20:17:11 CET 2006:

I don't think it would make a particularly big performance hit. The @ISA
stuff is not picked up by the parser yet and therefore is not reflected
in org.epic.core.model. I think it would make sense to add it there first
in analogy to the 'use' statements. Note that there is more than one way
to specify base classes in Perl, though.

Alternatively to extending org.epic.core.model, we could scan the source
file at the time of hyperlink activation using regular expressions (this
is done for the 'require' statements, I think), but I do not like this approach
as it neither benefits from the information provided by the parser and nor
does i contribute information which could be useful elsewhere (say, in a
"Type Hierarchy" view).