[fpc-devel] FPC dynamic libraries

[Michael Van Canneyt]

On Thu, 8 Feb 2007, Daniël Mantione wrote:

> 
> 
> Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
> 
> > > > Secondly, there are serious problems with this approach which make it unusable
> > > > for an IDE like Lazarus.
> > > > 
> > > > Assume I get a component instance from the plugin (MyObject), then extremely 
> > > > simple and basic statements like
> > > > 
> > > > If (MyObject is TComponent) then
> > > >   XYZ
> > > > 
> > > > will fail, even though MyObject is a TComponent, because the VMT of the 
> > > > MyObject TComponent parent resides in the library, and the VMT of TComponent
> > > > used in the If statement is inside Lazarus, causing the statement to fail, 
> > > > even though it should be true. When using packages, the statement will function
> > > > correctly.
> > > 
> > > I was talking a binary API, and that automatically disallows sending 
> > > classes through the API, because you want to prevent that an internal 
> > > change breaks your external API. Simply design the API in a proper way.
> > 
> > You can't, for Lazarus. You need the classes, that's what you need the
> > plugins for in the first place: to install additional components on the 
> > component palette. They must descend from the TComponent which is in
> > the IDE.
> > 
> > There is no way around it.
> 
> Yes, there is, we should not forget we have a facility in the language 
> to solve this problem: interfaces. Both components in the IDE as in the 
> plugin can implement the same interface, event though they have different 
> VMT layouts.
> 
> So, a component that you place in the component palette implements some 
> kind of "palette" interface, providing the IDE with the communications it 
> needs to work with the component.

Nice idea, but I think you'll end up creating a set of interfaces which 
describes completely TCollection/TCollectionItem TPersistent and TComponent, 
plus you'll need to completely redesign streaming from the ground up, and 
that's not possible for Delphi compatibility. You would loose all existing 
Delphi components out there.

Not to mention that you cannot insert a non-tcomponent in the tComponent
tree. And any 'component' from a package will be regarded as a non-tcomponent
by the code from classes, so: no component on form, no streaming.

Delphi's IDE uses interfaces everywhere, but still assumes TComponent/TPersistent 
as the base classes.

Michael.