On 04-04-2011 10:10, Alex Peshkoff wrote:
> 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.
I suppose nobody here wants to create N ways to report errors. Look at
intl interface mistakes: it can't report any useful error code/message.
> 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.
>
You would need to support the plugins which has the method and return an
error explicitly, so don't seems wise to insert such hacks in the design.
> 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.
>
I see nothing related to OLE2 here, as you said nobody need to addRef
after get an object with a method. So here things are ok.
But I disagree that objects must return from its constructor with
refcount=0. The only "advantage" on this approach is to make this code
valid:
RefPtr<T> obj(new T());
But note how bad more common code will do:
T* obj = new T();
obj->release(); // will make the refcount go to 0xFFFFFFFF and will
not release the object
Code managing the refcounter externally are much clear:
boost::shared_ptr<T> obj(new T());
// with T don't needing any refcount support
Adriano
------------------------------------------------------------------------------
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
