On 04/04/11 16:40, Adriano dos Santos Fernandes wrote: > On 04-04-2011 09:20, Alex Peshkoff wrote: >> What about always start functions with status parameter - I do not >> agree, because it's not required for upgradeInterface(). >> > It's required for correct usage of things by user. Errors must be > reported consistently, with the status parameter. > > Suppose we add a method in V4 which expect just an int parameter. Now > the plugin built initially for V4 has no chance to work with V3, cause > one can't return an error in status. User code should never pass a > function that throw to be used as non-existent methods.
This depends upon decision how to report error 'missing function in vtable' for particular interface. If some functions in it require status anyway, use of it in all functions is sooner of all correct. Let me suggest some other ways for other interfaces: 1. All functions return int, on success value >= 0 is returned, on error value < 0 is returned. If we reserve some negative value for missing function in vtable, we just return it in our added function. 2. Because added function is placed in same module as interface caller (supposing caller does not pass interface somewhere else), the most generic method is throw an exception. It will not pass module boundary, therefore can be caught successfully. I agree that in many cases presence of status as the first parameter is very good, but please - let's not add it at least to functions of status itself :-) >>> And I'm not saying it's technically incorrect. I'm saying it's kind of >>> unmaintainable code. Nobody would deduct this release where needed there >>> without a deep analysis on these classes. >> It can be deducted from generic rules of how to work with reference >> counted interfaces. >> > IMO we have some logical problem when trying to use objects who manage > its counter internally with smart pointers asking for them to do it. > > This was clear on the approach of objects being created with refcount=0 > and needing external addRef. Seems like a hack to pass them directly to > RefPtr which otherwise would never delete them. I see absolutely no logical problem here. In _this_ aspect OLE2 requirements are very clear and simple. ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
