Hi,
It is appears that you will need to add more commentary with your
examples so that I can understand them. ;)
The behaviors you are describing will effect the different tools in
ways I cannot predict at this time, so I will describe briefly how
semantic was designed to handle interesting languages.
First, there are a few standard tag types for traditional function
and OO based languages. The TAG constructor, however, can be used to
make any custom tag you want. The standard tags also allow you to add
any attributes you want to a give tag. This is in the lang-dev-guide
manual on tags in CVS.
If you use a tool which provides an unexpected answer, you will need
to look to see how it is constructed. Most library routines are
defined as "override methods". This means that a given major-mode can
provide a new implementation. The default behaviors are for C/OO
like languages.
Please read the manual (in 2.0 beta1c, or CVS) about override
methods in the lang-dev-guide for specific details. It sounds a bit
like your aspect oriented programming model examples you provided.
If you need to provide an implementation for a method not defined as
overridable, please let us know so that we can enable that feature.
The most likely location is probably in the semantic-analyzer which
will need to have alternate scoping rules.
When you combine those two features, it should be possible to get
the behavior you want out of any application that uses the core
utility functions in semantic.
In your example below about which version of "method1" is jumped to,
you will find that the new completion prompts (in CVS) for jumping to
tags handles that problem through a nifty "focus" mechanism when you
keep pressing TAB.
Eric
>>> Marcus Harnisch <marcus.harnisch@...> seems to think that:
>Hi Eric,
>
>Eric M. Ludlam writes:
> > >>> Marcus Harnisch <marcus.harnisch@...> seems to think that:
> > >struct Foo {
> > > member1: int;
> > >
> > > method1() :bool is {
> > > return(TRUE);
> > > };
> > >};
> > >
> > >somewhere else:
> > >
> > >extend Foo {
> > > member2: string;
> > >
> > > method1() :bool is only {
> > > return(FALSE);
> > > };
> > >};
> > >
> > >So I would like to see both member1 and member2 as well as both
> > >locations of method1() linked to the Foo entry in the database.[1]
> >
> > I'm assuming that you are using inheritance here. You are interested
> > in the class browser constructor in semantic-cb.el. You can use the
> > command `semantic-cb-speedbar-mode' to see your class hierarchy as
> > constructed from all source files that Emacs knows about.
>
>There is no inheritance involved in this simple example. I am just
>adding stuff to a previously defined class.
>
> > >[1] In real world the second definition of method1() replaces the
> > > first definition, but for code navigation we want to see all of
> > > the mess that has been created.
> >
> > Indeed, since the second method1 can call back to the first in some
> > instances.
>
>Bzzt. Wrong ;-) The code in the first definition of method1() gets
>replaced by the second definition. The first definition doesn't exist
>any longer.
>
>Other examples might append/prepend code to a method definition. But
>none of that makes a difference to me at this point since I am not
>interested in method bodies anyway..
>
> > Semantic has a wrapper for extent like things. Look in the first bit
> > of code in semantic-fw for the bit list.
>
>Ah, thanks. Got it.
>
> > The purposes of your extent are interesting.
>
>You mean as in "this food tastes... well, interesting"?
>
> > You may be able to avoid using extents in that way by the following
> > trickery, which I'm making up here as I go along.
> >
> > You could create special lex tokens as you do here, but not worry
> > about the extents.
> >
> > Next, set `semantic-lex-analyzer' to some intermediate function,
> > such as:
> >
> > (defun my-intermediate-lexer (start end &optional depth length)
> > "My lexer with pre processor built in."
> > (let ((tokens (my-other-lexer-made-with-macros start end depth length)))
> > (do-the-hokey-pokey tokens)))
> >
> > where `do-the-hokey-pokey' of course will pre-process the tokens,
> > stripping out the ones you don't want.
> >
> > Hmmm. That sounds exciting. I may have to try that sometime.
>
>Indeed. I was thinking about using the method I wrote about earlier
>where I looked at previous tokens. But I wasn't sure at which point
>the stream gets passed to the parser. Looking at you example I assume
>that the entire token stream is generated before the parser ever sees
>it. Is that true? Knowing that would make a lot of things much easier.
>
>I'll check that out.
>
>Thanks,
>Marcus
>
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|