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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
