On 04/01/11 19:01, Adriano dos Santos Fernandes wrote:
> On 01-04-2011 07:22, Alex Peshkoff wrote:
>> On 04/01/11 06:53, Adriano dos Santos Fernandes wrote:
>>> On 31-03-2011 10:44, alexpeshk...@users.sourceforge.net wrote:
>>>> Revision: 52620
>>>> http://firebird.svn.sourceforge.net/firebird/?rev=52620&view=rev
>>>> Author: alexpeshkoff
>>>> Date: 2011-03-31 13:44:22 +0000 (Thu, 31 Mar 2011)
>>>>
>>>> Log Message:
>>>> -----------
>>>> Remove reference counting where not appropriate
>>>>
>>> IMO situation of bogus release method and interaction with StackIface
>>> was just changed for an also bogus dispose method. Why do classes
>>> created and deleted by the engine, and only passed for plugins must
>>> implement a bogus disposable?
>>>
>>> All these changed classes completely lost they versioning numberings,
>>> making impossible to do future upgrades. Version number is good for all
>>> classes, and I see no relation of this to reference counters like it's
>>> current done.
>> Upgrading version of interface, passed from engine somewhere, makes no
>> sense. We must support old plugins with new firebird, but we were not
>> going to support new plugins on old firebird.
>>
> Alex, this don't make sense, sorry.
>
> Plugins must work and must be capable to decide what/if it can do,
> related to older and new versions. Now they can't even guess.
>
> Also all interface methods must start with status parameter and work
> consistent with our upgradeInterface. If it don't work this way, we have
> serious problem in our versioning system.
>
> And I insist we should not add bogus methods to classes. These classes
> are supposed to be user during the method call, and nobody externally
> should dispose them, so don't put a dispose method on it.
>
> This confusion seems as you still trying to map a completely different
> world to COM's IUnknwon.
>
> So a better hierarchy would be:
>
> IVersioned
> - IUnneededRefCounter
> --- ISomethingNotNeedingRefCounter
> - IDisposable
> --- ISomethingDisposable
> - ISomethindElse
>
I can agree with your arguments to make IVersioned base for all
interfaces in FB world.
What about always start functions with status parameter - I do not
agree, because it's not required for upgradeInterface().
What about dispose() in interfaces, doing nothing on it. Why is it
needed (at least in status interface) - because it can be created both
on stack/static and in dynamic memory. We create it on stack in yValve
in all calls to be able to substitute it instead missing user status,
passed by user. May be it's time to say stop, user must always pass
status to us? But this will be not like in ISC API. With this problem
solved I can agree to remove dispose from interfaces where it does
nothing. I do not see other time critical places where we need same type
of interface on stack/static and dynamic.
>>> Is this a refcounter hell starting? Constructor gets a reference to an
>>> object, release it and then use it later?
>>> GetPlugins(...)
>>> : ...,
>>> pluginSet(pluginInterface->getPlugins(...))
>>> {
>>> pluginSet->release();
>>> getPlugin();
>>> }
>> It's Ok if you look at what is pluginSet:
>> RefPtr<IPluginSet> pluginSet;
>>
>> getPlugins() returns IPluginSet object with reference counter == 1. RefPtr's
>> ctor increases it to be 2. Since this moment it's not class GetPlugins who
>> owns this object, it's member pluginSet now owns that object, and therefore
>> release() is called.
>>
> 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.
------------------------------------------------------------------------------
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
