[Qt-interest] anyone know why QDir::mkpath() isn't static?
Constantin Makshin
cmakshin at gmail.com
Tue Apr 12 19:18:05 CEST 2011
What about static makePath(const QString& path) function (may be also removePath(const QString& path) for "symmetry", as a static version of rmpath())? Then:
bool QDir::mkpath (const QString& dirPath) const
{
return makePath(QFileInfo(dirPath).isAbsolute() ? dirPath : absoluteFilePath(dirPath));
}
bool QDir::rmpath (const QString& dirPath) const
{
return removePath(QFileInfo(dirPath).isAbsolute() ? dirPath : absoluteFilePath(dirPath));
}
In that case you'll both keep API compatibility and solve the problem/inconvenience of using mkpath() and rmpath() with absolute paths.
On Tuesday 12 April 2011 20:26:31 Thiago Macieira wrote:
> Em terça-feira, 12 de abril de 2011, às 09:19:38, Scott Aron Bloom escreveu:
> > I have found there are a number of little idiosyncrasies in the QFile,
> > QFileInfo, and QDir code that can be confusing and worst case create a
> > bug.. You just get used to them
> >
> > With mkpath... I would prefer if there was a static as well as a non-static
> > member... I wouldn't even mind if the QDir threw an assert on the static
> > member if the path sent in was relative.
>
> For those interested, we're still having a discussion on the ugliness and
> wrongs of QFile, QDir and QFileInfo in the #qt-labs channel. There's a lot
> that could be done better and the developers agree.
>
> The question is: when the time comes for when a source-incompatible is
> permitted, what is better, to keep compatibility with thousands of existing
> programs or to make a new, better but incompatible API?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110412/c0fa9865/attachment.bin
More information about the Qt-interest-old
mailing list