[fpc-devel] interfaces vs classes in dll

[Michael Van Canneyt]

On Fri, 30 Nov 2007, Paul Ishenin wrote:

> Michael Van Canneyt wrote:
> 
> > > > Classes:
> > > > - No reference counting mess. - Easier to grasp conceptually.
> > > >   
> > > In plugin dll?
> > 
> > Sure. Why not ? Obviously, the DLL needs to use packages, but that is
> > understood.
> 
> I mean what is easier to grasp conceptually when you use class in dll instead
> of interface? I think nothing. Where is written that either we use (classes +
> packages) or (interfaces - packages)?

Because when you write "DLL", this usually means "- packages" ?
I don't see the need of writing a DLL if you use packages; 
Better write a package instead.

> 
> Why you should use reference counting?

Because when you use interfaces, reference counting will pop up somewhere
along the line to keep track of your 'live' interfaces. When a class
instance is destroyed, it's destroyed...

> 
> > > > - You can use ansistrings. Interfaces require widestrings. (olestrings
> > > > to be
> > > > exact)
> > > >   
> > > Who told you this? Interface <> com object
> > 
> > COM has nothing to do with it.
> > 
> > When you pass an interface that uses ansistrings to a DLL, the ansistrings
> > in it (or referenced by it) may be disposed of by the wrong memory manager.
> > 
> > Since I assume the DLL use is the scenario that is wanted, it de facto means
> > that you must use widestrings.
> > 
> > The alternative is that you require that you can set the memory manager
> > of the plugin. This, in turn, is not feasible, because some plugins will
> > need the C memory or other memory managers. (see the whole borland
> > sharedmm.dll mess)
> > 
> > In short: DLL => No ansistrings in interface.
> > 
> > (and guess why: reference counting, same disease as for interfaces)
> 
> Same misreading. Nobody written interfaces without packages. So you can use
> any type inside interface.

I understand that, but if you intend to use packages, I don't see 
the use of interfaces. Using DLL's more or less forces the use of
interfaces. 

I find classes more natural than interfaces. It 'just works'. 
Not so with interfaces, because you must do a typecast every time.

Compare

Function GetPluginInterface : ISOmeThing;

begin
  X:=MyPluginObjectXYZ.Create;
  Result:=X as ISomething;
end;

With

Function GetPluginInterface : TSomeClass;

begin
  Result:=MyPluginObjectXYZ.Create;
end;

If you use encapsulation well, there is IMHO no reason for interfaces.
I have about 2 million lines of reasonably difficult plugin code, and
not a single interface in it. There is no need if you use packages.
 
> > > > > What if someday there are packages? 
> > > > >     
> > > > It'll work transparantly.
> > > >
> > > >   
> > > > > What if someday there is a closed source dll plugin?
> > > > >     
> > > > If it is a package, there is no problem.
> > > >   
> > > And even after extending class old class dependant plugins will work? How?
> > 
> > Because you use packages. A DLL will never work.
> 
> And how package system will redirect pointers from old plugin dll (which is
> also package) to new methods locations?

No-one. The DLL must be recompiled anyway if you use packages.
And this is also true if you use interfaces, so using interfaces
will not solve the problem you mention.

Michael.