On 13.01.2012 14:10, Mathias Hasselmann wrote:
Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo:
On 13 January 2012 12:32, Mathias Hasselmannmath...@openismus.com wrote:
what about the slightly more garden-variety approach of deprecating
the old one and introducing a new
On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel syntheti...@gmx.net wrote:
But to think first about what createRequest really does is a good idea:
It not only creates a request, it also sends it, so why not rename it to
'doRequest' or something similar which is different to 'createReply'
which
On 1/15/12 5:08 PM, ext Richard Moore r...@kde.org wrote:
On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel syntheti...@gmx.net wrote:
But to think first about what createRequest really does is a good
idea:
It not only creates a request, it also sends it, so why not rename it to
'doRequest' or
Off topic:
There would still be silent errors for people who have reimplemented
the createRequest method (it's virtual).
Technically interesting here is the question how such a
situation cloud be managed? Using C++11 'final' would
prevent the reimplementation. But using pre C++11, the
On Sunday, 15 de January de 2012 20.25.17, Peter Kuemmel wrote:
Technically interesting here is the question how such a
situation cloud be managed? Using C++11 'final' would
prevent the reimplementation. But using pre C++11, the only
idea I have is to define a dummy function with a different
On Friday, 13 de January de 2012 08.14.41, Peter Kuemmel wrote:
Well, having method createX which creates Y doesn't sound good to me
either.
Yes, this is worse than a binary-only bug.
I don't know the policy for API changes for Qt 5.0,
but when such a thing couldn't be fixed, nothing else
Am Freitag, den 13.01.2012, 14:10 +0200 schrieb Robin Burchell:
2012/1/13 Thiago Macieira thiago.macie...@intel.com:
So, changing the name of this function is:
- of little practical benefit
- not 100% automatable without a code scanner
- dangerous, as it creates silent bugs
what
On 13 January 2012 12:32, Mathias Hasselmann math...@openismus.com wrote:
what about the slightly more garden-variety approach of deprecating
the old one and introducing a new method?
Maybe we should check the premise of this discussion first.
Does that method really have the wrong name? It
On Friday, 13 de January de 2012 13.32.27, Mathias Hasselmann wrote:
Am Freitag, den 13.01.2012, 14:10 +0200 schrieb Robin Burchell:
2012/1/13 Thiago Macieira thiago.macie...@intel.com:
So, changing the name of this function is:
- of little practical benefit
- not 100% automatable
Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo:
On 13 January 2012 12:32, Mathias Hasselmann math...@openismus.com wrote:
what about the slightly more garden-variety approach of deprecating
the old one and introducing a new method?
Maybe we should check the premise of
On 01/13/2012 02:10 PM, ext Mathias Hasselmann wrote:
(...)
Surely startRequest() would have been a better name.
But really not sure it is worth the hassle of changing it.
Still Robins suggestions shows a practical approach.
I don't really think it is worth changing it, I think for 5.0 so far
createReply doesn't make sense to me.
createRequest is perfectly fine in a sense that we query the server, and it
returns a reply out of it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On 13.01.12 16:25, Sylvain Pointeau wrote:
createReply doesn't make sense to me.
createRequest is perfectly fine in a sense that we query the server,
and it returns a reply out of it.
Well, it does make sense to me :-)
The request (QNetworkRequest) is already created. What the function
Well, having method createX which creates Y doesn't sound good to me
either.
Yes, this is worse than a binary-only bug.
I don't know the policy for API changes for Qt 5.0,
but when such a thing couldn't be fixed, nothing else
is worth braking source code compatibility.
I would fix it
Giuseppe D'Angelo dangelog at gmail.com writes:
Being an API break, do you see any good motivation to justify it?
Yes, it can only be done in new major version. When if not now?
(I agree that the method name is wrong since it creates the reply, but
breaking software just because doesn't
On Monday, 9 de January de 2012 18.46.01, Piotr Dobrogost wrote:
Giuseppe D'Angelo dangelog at gmail.com writes:
Being an API break, do you see any good motivation to justify it?
Yes, it can only be done in new major version. When if not now?
Never.
(I agree that the method name is wrong
16 matches
Mail list logo
