> On 08-04-2011 13:43, [email protected] wrote:
>> Revision: 52693
>> http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
>> Author: alexpeshkoff
>> Date: 2011-04-08 16:43:05 +0000 (Fri, 08 Apr 2011)
>>
>> Log Message:
>> -----------
>> Use interface IBlrMessage instead passing C++ class pointer to API
>> interface's functions
>>
> I'm *very* against this *undiscussed* change.
You also against endless discucssions of every tiny code change, isn't is ?
:)
> Pointer to plain struct is know to be portable and usable by the clients
> we expect to use our API.
Plain struct ? It was declared as "class", not as "struct", sorry. If you
want understanding
from other developers, please, make you ideas clear. Else there will be such
"incidents".
Something obvious for you is not obvious for me and far not obvious for end
users. This is life.
Btw, i see no problem curently. Alex made change but it is not means it
can't be undone if
necessary.
Also, please, when you introduce new class or struct or constant - any bit
of code in API -
please, make comments about its intended usage. Also, please, write explicitly
who is responsible
for implementation of every interface (firebird itself, plugin creator or
application developer) and how
to obtain instance of this interface. This is request for all developers, not
for Adriano only :) API
headers should be as much self documented as possible and new readers should
understand it
without huge efforts.
> This change puts a very number of extra virtual call for each (from each
> layer) method called. Considering the methods involved are ones that are
> heavily called, this is going to make a vary large overhead.
Could you point me - where do you see the large overhead ? Probably i
missed some loop with
hundreds calls of this methods ? Or it is just a few calls per whole API call ?
I see no problem to revert this change in favor of "struct", but i'm
against "class" in public API.
Public API should use "struct" (as it have no methods) and pure virtual classes
(as it have no data
and no methods implemented). Else at some day someone will add methods into
your POD "class
Message" and ruin our public API.
And last point. Please, replace name Message with something more exact. The
structure you
named "Message" is not a message itself - it is sooner message description or
message metadata.
Names should be clear and not generic when possible. Name "Message" is
misleading, sorry.
Lets make new entities clear and easy to understand.
Regards,
Vlad
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
