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)?
Why you should use reference counting?
- 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.
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?
Best regards,
Paul Ishenin.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
