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 differen
On Sun, Jan 15, 2012 at 7:25 PM, Peter Kuemmel wrote:
>
> 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 'fi
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, th
On 1/15/12 5:08 PM, "ext Richard Moore" wrote:
>On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel 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 whic
On Sun, Jan 15, 2012 at 2:25 PM, Peter Kümmel 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 is as misleadin
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 Hasselmann wrote:
what about the slightly more garden-variety approach of deprecating
the old one and introducing a new method?
>>>
>>>
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
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 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
Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo:
> On 13 January 2012 12:32, Mathias Hasselmann 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 discuss
On Friday, 13 de January de 2012 14.10.09, Robin Burchell wrote:
> 2012/1/13 Thiago Macieira :
> > 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 about the slig
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 :
> > > So, changing the name of this function is:
> > > - of little practical benefit
> > > - not 100% automatable without a code s
On 13 January 2012 12:32, Mathias Hasselmann 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 is called
> "cre
Am Freitag, den 13.01.2012, 14:10 +0200 schrieb Robin Burchell:
> 2012/1/13 Thiago Macieira :
> > 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 about the slig
2012/1/13 Thiago Macieira :
> 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 about the slightly more garden-variety approach of deprecating
the old one and introducing a n
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, noth
>
> 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
On Monday, 9 de January de 2012 18.46.01, Piotr Dobrogost wrote:
> Giuseppe D'Angelo 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 sinc
Giuseppe D'Angelo 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 sound good
On 9 January 2012 18:07, Piotr Dobrogost wrote:
> Hi!
>
> Is QNetworkAccessManager::createRequest
> (http://doc.qt.nokia.com/qt5/qnetworkaccessmanager.html#createRequest) going
> to
> be renamed to proper name QNetworkAccessManager::createReply in Qt5?
Being an API break, do you see any good mot
Hi!
Is QNetworkAccessManager::createRequest
(http://doc.qt.nokia.com/qt5/qnetworkaccessmanager.html#createRequest) going to
be renamed to proper name QNetworkAccessManager::createReply in Qt5?
Regards
Piotr Dobrogost
___
Development mailing list
Devel
21 matches
Mail list logo
