ParsingEnvironment??

[Andreas Pakulat]

On 09.02.08 12:51:39, David Nolden wrote:
> On Saturday 09 February 2008 09:24:36 Andreas Pakulat wrote:
> > IdentifiedFile(HashedString(m_url.path()));
> >
> > > You can simply address your files by using IdentifiedFile(fileName, 0) or
> > > similar, and construct all your HashedString file-names using
> > > KUrl::prettyUrl() as needed(ond of course also the opposite direction
> > > wherever necessary).
> >
> > Uhm, prettyUrl()? I think either url() or path() (If I only support
> > local filepaths) is better, as prettyUrl is intended for user display,
> > not for programatic usage.
> 
> I wasn't sure whether we really only support local file-paths.

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.

> 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.

Except for presenting urls to the user you should always use KUrl::url()
to convert to a string.

> 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)?

> > Btw: Haven't seen any replies from you in the mails, are you coming?
> 
> Yep I'm coming, I've replied about 2 or 3 times all in all, dunno why you 
> didn't get them.

Hmm, seems my memory is bad :)

Andreas

-- 
You will stop at nothing to reach your objective, but only because your
brakes are defective.