On 14/06/2012 09:23, Mark Rotteveel wrote:
> On 14-6-2012 12:50, Adriano dos Santos Fernandes wrote:
>> On 14/06/2012 06:13, Alex Peshkoff wrote:
>>> For me this looks like regression, sorry.
>>>
>> If you talking about specific subject about warning removal, I'd instead
>> call it "let bad legacy
On 06/14/12 18:38, Vlad Khorsun wrote:
>> Is it enough to agree that keeping warnings in our API is the only
>> correct solution?
> I, personally, prefer to have warnings, but, probably it should be
> delivered not using status-vector. If we can produce and deliver many
> warnings per stateme
On 14-6-2012 12:50, Adriano dos Santos Fernandes wrote:
> On 14/06/2012 06:13, Alex Peshkoff wrote:
>> For me this looks like regression, sorry.
>>
> If you talking about specific subject about warning removal, I'd instead
> call it "let bad legacy and non-feature interfere with new design for no
>
On 14-6-2012 16:38, Vlad Khorsun wrote:
>> Is it enough to agree that keeping warnings in our API is the only
>> correct solution?
>
> I, personally, prefer to have warnings, but, probably it should be
> delivered not using status-vector. If we can produce and deliver many
> warnings per state
> Is it enough to agree that keeping warnings in our API is the only
> correct solution?
I, personally, prefer to have warnings, but, probably it should be
delivered not using status-vector. If we can produce and deliver many
warnings per statement (or per API call) it will be the best, as fo
On 14/06/2012 09:33, Alex Peshkoff wrote:
> On 06/14/12 15:02, Adriano dos Santos Fernandes wrote:
>> On 14/06/2012 07:50, Adriano dos Santos Fernandes wrote:
>>> // Original method
>>> virtual IAttachment* attachDatabaseNoThrow(IStatus* status, const char*
>>> filename)
>>> {
>>> ...
>>> }
>>
On 14/06/2012 09:31, Alex Peshkoff wrote:
> On 06/14/12 14:50, Adriano dos Santos Fernandes wrote:
>> On 14/06/2012 06:13, Alex Peshkoff wrote:
>>> For me this looks like regression, sorry.
>>>
>> If you talking about specific subject about warning removal, I'd instead
>> call it "let bad legacy a
On 06/14/12 15:02, Adriano dos Santos Fernandes wrote:
> On 14/06/2012 07:50, Adriano dos Santos Fernandes wrote:
>> // Original method
>> virtual IAttachment* attachDatabaseNoThrow(IStatus* status, const char*
>> filename)
>> {
>> ...
>> }
>>
>>
> Must also say that implementation of this met
On 06/14/12 14:50, Adriano dos Santos Fernandes wrote:
> On 14/06/2012 06:13, Alex Peshkoff wrote:
>> For me this looks like regression, sorry.
>>
> If you talking about specific subject about warning removal, I'd instead
> call it "let bad legacy and non-feature interfere with new design for no
>
On 14/06/2012 07:50, Adriano dos Santos Fernandes wrote:
>
> // Original method
> virtual IAttachment* attachDatabaseNoThrow(IStatus* status, const char*
> filename)
> {
> ...
> }
>
>
Must also say that implementation of this method is done with some
generated code that runs the method code ins
On 14/06/2012 06:13, Alex Peshkoff wrote:
> For me this looks like regression, sorry.
>
If you talking about specific subject about warning removal, I'd instead
call it "let bad legacy and non-feature interfere with new design for no
reason".
> I suppose we should find better way to do this. I've
On 06/11/12 20:01, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Warnings were always a second-class citizen in Firebird. Usage of them
> in the design of new features were already rejected because "nobody
> checks them".
>
> As I told some time ago, I was testing a scheme to implement/use our
> p
11.06.2012 18:01, Adriano dos Santos Fernandes wrote:
> There is one problem. We can't make it really C++ friendly without
> removing the need to pass a status everywhere, but there is no way to
> return warnings without them. We can maintain the status parameter, but
> then, it makes things still
Hi!
Warnings were always a second-class citizen in Firebird. Usage of them
in the design of new features were already rejected because "nobody
checks them".
As I told some time ago, I was testing a scheme to implement/use our
public interfaces in a more C++ way.
That is most related to exception
14 matches
Mail list logo
