[Development] Compatability break in QUrl in Qt 4.8

Thiago Macieira thiago.macieira at intel.com
Mon Jan 30 16:34:15 CET 2012


On Monday, 30 de January de 2012 13.30.32, ext-aapo.haapanen at nokia.com wrote:
> The change concerns how toLocalFile() handles relative urls. Before 4.8 it
> returned the path, but in 4.8 it returns an empty string. 4.7:
> QUrl("dir/file.html").toLocalFile(); returns "dir/file.html" 4.8:
> QUrl("dir/file.html").toLocalFile(); returns QString()
> 
> This change has been previously discussed in QTBUG-19827, and the conclusion
> was that this is an intentional break of binary and source compatibility.

There was no break of binary or source compatibility. It was a change of 
behaviour because the previous behaviour was considered buggy (by me).

Every bug fix is a change in behaviour.

> The documentation doesn't specify how relative urls are handled by the
> function. I can see how both behaviours make some sense. A relative url can
> refer to a local file, but that can't be deduced from the url alone. 4.7
> took a more lenient approach and returned the relative path. In 4.8
> relative urls must be resolved first, and only when we know for sure that
> the url refers to a local file, the path is returned.
> 
> The behaviour of 4.7 gives application a bit more flexibility on how to
> handle the urls. I can't see a clear benefit from the new behaviour.

>From my point of view, I don't see how writing proper code can be worse than 
writing sloppy code. We don't want sloppy code like:

	QString filename = url.toLocalFile();
	if (!filename.isEmpty()) {
		// it's a local file, use it
	}

We can't use isLocalFile() either because the two functions must be linked: if 
one returns non-empty, the other must return true.

You can't write:

	if (!url.isAbsolute())

Because you can have relative URIs referring to both local and remote 
resources. That tells you nothing.

You can't write:

	if (url.scheme().toLower() == "file")

Because a scheme-less relative URI could refer to a local resource too if the 
base URL is local.

The *only* way to know if a relative URI refers to a local resource is to 
resolve it against the base URL first. You do that by writing:

	QUrl absolute = baseUrl.resolved(url);
	if (url.isLocalFile()) {
		// it's a local file
	}

Since you have to pass the relative URI through QUrl::resolved *anyway* in 
order to write the proper code, I don't see why QUrl::toLocalFile should be 
lenient.

The above *must* be done for any remote sources of URIs.

> This is an unnecessary break of compatibility between minor versions, and
> this has been found to break some paid applications in Ovi Store. For that
> reason I would like to see the behaviour reverted for 4.8.

I say the break is necessary. It "breaks" the applications because it made the 
already-existing bugs in them be visible. I am saying those applications are 
buggy and need to be fixed anyway. Qt 4.8 simply makes them need to be fixed 
*now*.

That said, I could be convinced that the effort is too great and that the 
possibility of the already-existing bugs showing up. In that case, I could be 
convinced of changing this behaviour in Qt 4.8.1 back to what it was in 4.7. 
But I will definitely not be convinced about that change in Qt 5.

I don't want to do that. I planned on having this change in Qt 4.7 but we 
reverted because it was coming in too late. So we accepted in having the buggy 
behaviour for another version. We need to have it in some time, sooner rather 
than later.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120130/1e37384e/attachment.sig>


More information about the Development mailing list