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. > 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. > Methods added later are generally not "core-methods" and not very > performance sensitive. That's not always true. For example there are plans to add batch SQL API for DML operators. Methods needed for it will be added first of all for performance reasons. But once again - when we do not need virtual calls for version check it's not critical. > I propose we check they versions (it's an if) > when calling them. 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. > If you feel necessary, we can fill vtables with > doNotImplemented method for 5 or so more methods than the initial method > count of the first version, so the next 5 methods added in subsequent > versions will not need the if-check and may be called directly. IMHO that's not a solution. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
