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, [email protected] 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
>> 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.
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
