On Monday, 31 de October de 2011 16:40:32 Peter Hartmann wrote: > On 10/25/2011 11:59 AM, ext Thiago Macieira wrote: > > I can't post the code just yet, but I can post the new API. > > > > Questions: > > - I un-deprecated fromEncoded and toEncoded, as they're used everywhere. > > > > Should I do the same for fromPercentEncoding and toPercentEncoding? They > > convert from QString to QByteArray and vice-versa, while > > QByteArray::fromPercentEncoding operates only on QByteArray. > > I would assume they are in widespread use as well; In my opinion you > could well keep those methods, I would expect such a method in QUrl > rather than in QByteArray.
Ok, I'll un-deprecate those.
> > - QUrl::url() returns a QString. It should have a "to" prefix, since it
> >
> > returns a temporary. It's the exact same function as toString(). Should it
> > be kept?
>
> If it does exactly the same as toString(), why have it at all? Is it to
> have an equivalent to scheme(), host() etc.?
Hmm... it was the getter of setUrl(). I'm guessing I should remove the setter
too.
> > - QUrlQuery does not keep the order of the items (it's kept in a hash).
> > Is
> >
> > the order important?
>
> I would prefer if the order was kept; e.g. for using OAuth, the
> parameters need to be sorted in alphabetical order and then that string
> needs to be hashed; changing the order in that case would also change
> the hash value and would result in an error when using OAuth.
>
> So I think there are use cases where parameter ordering is important.
I see. Do you have any OAuth testcases I could add to make sure QUrlQuery
works as expected?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
