How can I associate a codemodel item with its language?

[Milian Wolff]

David Nolden, 31.08.2009:
> Am Montag 31 August 2009 22:07:30 schrieb Milian Wolff:
> > David Nolden, 31.08.2009:
> > > Am Montag 31 August 2009 21:01:00 schrieb Milian Wolff:
> > > > David Nolden, 31.08.2009:
> > > > > Am Mittwoch 26 August 2009 01:30:02 schrieb Milian Wolff:
> > > > > > I want to add per-language grouping to the class browser, but am
> > > > > > stuck:
> > > > > >
> > > > > > It uses the CodeModel to get the items, but how do I decide to
> > > > > > which language a given item is associated? Not even declarations
> > > > > > / contexts seem to have any association with a language...
> > > > >
> > > > > Top-contexts have an association to the language.
> > > > >
> > > > > The problem is that you cannot access those from within the
> > > > > code-model right now I think.
> > > > >
> > > > > So the simplest way would be using the file-extensions to do the
> > > > > filtering, as that is basically all that is known at that point.
> > > > >
> > > > > Greetings, David
> > > >
> > > > I don't like this workaround, maybe I should fix the real issue? Or
> > > > would associating the language with a code model result in increased
> > > > disk-size for the repo again or something like that?
> > >
> > > The code-model is an extremely simplified view of the code, and it is
> > > good that way as it allows efficiently accessing only the really most
> > > important information.
> > >
> > > Right now it is just a map from a filename to a set of
> > > declaration-names within minimum information:
> > > ( Filename -> [ [Declaration-name, declaration-kind], .... )
> > >
> > > And I don't know where the information about the language should be
> > > integrated there. The "Declaration-name" entries are not bound to a
> > > specific declaration, and there could be multiple declarations of the
> > > same item, maybe even from an arbitrary set of items.
> > >
> > > What could be done without paying a high price would be adding a
> > > mapping (Filename -> language), but that would also not really work in
> > > your case as there can be multiple languages for one file.
> > >
> > > > I mean grouping by file extension could potentially really be error
> > > > prone, lets do it correctly and use the information we have... And I
> > > > bet accessing the topducontext for every class would be too slow,
> > > > right?
> > >
> > > If it would use the same information for assigning languages to
> > > filenames that is available to the language-controller, it would be
> > > exactly equivalent. The problem is that the languages are assigned
> > > through mimetypes, and that stuff is using KUrls, and is very
> > > inefficient.
> > >
> > > > Though I have to admit that even in the TopDUContext I wouldn't have
> > > > the slightest clue how to get it's language plugin to query
> > > > ::name()...
> > >
> > > I think each top-context has a language() function, or at least each
> > > ParsingEnvironmentFile. But I guess using that information for grouping
> > > in the class-browser is not really an option, as you would first have
> > > to load the top-context, which is too slow.
> >
> > Ah, ok:
> >         topCtx->parsingEnvironmentFile()->language();
> >
> > But yeah, I bet that would be too slow...
> >
> > > > The only thing I know of is the ParsingEnvironmentFilePointer, but
> > > > that is per-url. I bet this would be a problem as soon as we have
> > > > e.g. JavaScript support and files where we have both, JavaScript
> > > > declarations and PHP declarations in the same file (somewhat ugly imo
> > > > but you never know what users do...).
> > >
> > > It is not per-url, but per-topducontext. An arbitrary amount of
> > > topducontexts can be created for each url.
> >
> > Indeed, with topCtx->parsingEnvironmentFile() that association is there.
> > I just looked at parsingEnvironmentFile and that had only a ctor with
> > urls which I completely misinterpreted.
> >
> > > > Can you give me some pointers on how/where to integrate something
> > > > like ParsingEnvironmentFilePointer for CodeModel items?
> > >
> > > You mean a direct link between the code-model and
> > > ParsingEnvironmentFile? As said, this is not a 1:1 relationship: There
> > > can be an arbitrary amount of top- contexts for each url, and an
> > > arbitrary amount of declarations for each code- model item. So such a
> > > direct link can not be cleanly created. The code-model can only be used
> > > to get a very simplified structure of the code, and in order to make
> > > the step into the real duchain, an indirect query has to be done.
> >
> > Indeed it is not a 1:1 relationship. But we need some way to have the
> > classbrowser know the language for a given declaration it gets from the
> > code model. I'm still unsure how this would work, but that it is a
> > problem, beside not having a proper grouping by language, is shown with
> > this:
> >
> > Have a project with a cpp and a php file:
> >
> >
> > test.php:
> > <?php
> > class test {
> > function test(){}
> > function findPhpClass() {}
> > var $phpmember;
> > }
> >
> > test.cpp:
> > class test {
> > test(){}
> > void findCppClass() {}
> > int cppmember;
> > };
> >
> > Result:
> > http://imagebin.ca/view/vNZO953M.html
> >
> > I mean this is totally expected, since it only know the identifier for a
> > declaration, not its language. It queries the persistent symbol table
> > when the item gets expanded, and both times it uses the first item in the
> > persistent symbol table...
> >
> > So we really need _any_ way to associate the lang with an item in the
> > class browser... I just thought we'd need to extend the code model since
> > that's what the class browser uses...
> >
> > Is there another way that would also be efficient enough?
>
> In this case a very simple one:
> >From multiple declarations in the persistent symbol table, just pick the
> > one
>
> that has the same url as the file from the code-model. That should fully
> resolve this issue.
>
> Greetings, David

And per-language grouping in the class browser is a WONTFIX then, correct? 
Since I don't see a way to implement it with the current architecture.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090831/7371e025/attachment.sig>