[fpc-devel] interfaces vs classes in dll

[Paul Ishenin]

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.