On 23/10/2014 13:42, Alex Peshkoff wrote:
> On 10/23/14 18:56, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> To not check class version in each method call, cloop-based interfaces
>> implement class-upgrade at return and argument passing.
>>
>> If everything is simple, it (the mechanics) works. But not everything is
>> simple.
>>
>> We have structs (Dtc::start - with DtcStart) with interfaces and
>> pointers to classes (DbCryptPlugin::setKey), where a number of elements
>> may be passed.
>>
>> It's not impossible, but I feel as a great level of complication to add
>> to cloop things like IN/OUT parameters and instruction of how to decode
>> length of buffers. And later we'll add another set of complication to deal.
>>
>> Also, I really don't believe that class-upgrade are going to work. There
>> are various problems, like who allocate/deallocate memory for vtables,
>> how to call a standard upgrade function (must be in IMaster/IUtl), but
>> it's not always accessible (you can't just call fb_get_master, multiple
>> client library may be dynamically loaded).
> Must say that we suggested in cloop fast version check (no virtual calls 
> needed) there is no big difference between version upgrade and explicit 
> version check. 2-3 additional machine instructions is nothing when doing 
> virtual API calls. I.e. I agree that now version upgrade is not a 
> requirement.

Ok. I thought you were against it even with the if-check.


>> I propose something different.
>>
>> Methods appeared in the first version of an interface must never be
>> checked, as they will be always there.
> We should learn to distinguish what method is last. Not ot say it's too 
> hard task but this must be done if we want to relay on it.

I may add to cloop something to mark a set of methods for a version.

> I want to point you to one detail. It should be possible to specialize
> (in some way) action to be taken when interface version does not match
> to caller requirements. Currently function to upgrade version is
> specialized for one interface in trace plugin. It's good idea to have
> same functionality when checking version. 

I see it, but I really don't agree. I don't understand how one could
call a method and just ignore if it's not called.

This case must be for user to check the version before call. If we don't
mess with the version field, it will be constant and the user may check it.

Anyway, I think the police can deal with such cases.


Adriano


------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to