ParsingEnvironment??

[David Nolden]

On Saturday 09 February 2008 13:40:42 Andreas Pakulat wrote:
> On 09.02.08 12:51:39, David Nolden wrote:
> We don't actually. But AFAIK there's no code yet to download the remote
> files to parse them.
>
> > Is that the
> > case? Having that stated clearly would make some things significantly
> > easier.
>
> No no, the plan is to keep KUrl (else we'd have QStrings for paths
> everywhere) and be prepared to have remote files to parse.

My personal hope is that this whole problem will be solved some time 
correctly, using kio_fuse or a similar technology within kdelibs. I think 
it's insane forcing hundreds of apps to add error-prone code, instead of 
solving the problem in one place.

The problem is not only downloading files for parsing, but also searching for 
include-files and include-paths(any idea how to run the include-path resolver 
remotely? ;), managing patches in teamwork, etc.

> > I have always used prettyUrl while converting to HashedString, because I
> > think it also does some normalization.
>
> The problem with prettyUrl is that
>
> KUrl u;
> u != KUrl(u.prettyUrl())
>
> at least not in the general case. In particular passwords are stripped,
> and possibly other things.

Yep, but the idea is that the du-chain is stored to the disk some time, so 
removing sensible stuff like passwords before putting the url into the 
du-chain would be a good idea, so the whole du-chain works with the same kind 
of urls, and comparing the url of files loaded from the duchain cache with 
actual urls would not cause any headaches once we have the caching.

> > What about adding a constructor IdentifiedFIle(const KUrl&, int id = 0)
> > that would do the conversion, then you could save a lot of typing.
>
> I really don't know. Is it a problem if one reads the code and doesn't
> see its an identified file (because its created implicitly)?

An IdentifiedFile is nothing more than a file-name connected with an integer, 
so this is really a mini-conversion. Personally I hate code 
like "IdentifiedFile(HashedString(m_url.path()));" and similar things with 
AbstractType::Ptr that kdevelop is full of. I'd prefer solving the thing in 
one single place, instead of blowing up the whole code-base with such stuff. 
After all it's also a kind of code-duplication.

greetings, David