The idea of using interfaces is once published, you do not change the interface. If you need to make any changes, you publish another interface (with a different GUID) and as long as the implementation is backwards compatible (ie., supports both interfaces), you do not need to recompile the consumers.
----- Original Message ----- From: "Phil Middlemiss" <[EMAIL PROTECTED]> To: "NZ Borland Developers Group - Delphi List" <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 8:27 AM Subject: Re: [DUG] Passing Objects to a DLL > We have a plugin mechanism that we are using the DLLs for. We looked at BPLs > when we were starting out with the plugin mechanism. The biggest problem > with them was that if a unit changed that was shared by multiple BPLs and/or > the main app, then all of them needed to be updated which kind of defeated > one of the purposes of the plugin system that allowed smaller update > downloads for just the plugins that have been changed. > > We also use interfaces a little bit, but did not want to build our plugin > architecture on them either since a new method/property on an underlying > object requires either a new iterface to be added, or the existing one > changed which then requires, again, that all plugins that use that changed > interface, and the main app, need to be updated. With approx 10000 users we > could just imagine the support nightmare as people somehow ended up with > BPLs or interfaces that were out of sync! > > In case anyone is interested (probably not) - in the end we built more of a > script-like mechanism for plugins. That way a plugin only needs to respond > to events/commands that it supports (the script commands are versioned) and > likewise the app can ignore requests that it doesn't support. Seems to be > working OK so far, although as you can see from the original thread post, > there are issues that need working around. > > I suppose you could use the same "either supports it or doesn't" approach > with interfaces also, but trying to provide our current functionality with > interfaces is a daunting task - there are a lot of classes! > > Cheers, > Phil. > > ----- Original Message ----- > From: "Dennis Chuah" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 08, 2004 9:14 PM > Subject: Re: [DUG] Passing Objects to a DLL > > > > > > BPL's are the only way to go. You typically version your BPL's by > appending > > the version number to the filename. > > > > If you have to stick to DLL's try using interfaces and query for an > > interface rather than whether an object belongs to a hierarchy. Interface > > > querying uses GUID's and not VMT pointers. > > > > >From: "Phil Middlemiss" <[EMAIL PROTECTED]> > > > > > >Thanks Max, I thought it was something like that, but didn't know the > > >specifics. BPL's are out of the question for us... we looked at that and > > >ruled it out earlier since the versioning nightmare is even worse than > with > > >DLL's. Is the BPL the only way around it? > > > > > >Cheers, > > >Phil. > > >----- Original Message ----- > > >From: "Max Nilson" <[EMAIL PROTECTED]> > > >To: "'NZ Borland Developers Group - Delphi List'" <[EMAIL PROTECTED]> > > >Sent: Wednesday, September 08, 2004 5:07 PM > > >Subject: RE: [DUG] Passing Objects to a DLL > > > > > > > > > > Phil Middlemiss asks: > > > > > > > > > When an object is passed to a DLL it comes across fine and all > > >properties > > > > and > > > > > methods can be accessed, but somehow the class information gets > > >handled > > > > > differently. Using the "is" comparison fails when it should work - > > >even > > > > > InheritsFrom doesn't work. We've got around this in the past by > using > > >a > > > > > recursive routine to compare class/ancestor names but I'm beginning > to > > > > wonder > > > > > if there is a trick that I have missed somewhere. > > > > > > > > > Can anyone shed any light on this? > > > > > > > > Class type comparisions are done using the VMT tables that are > generated > > >for > > > > each class. When you compile a DLL a separate copy of the VMT's are > > >linked > > > > in, leading to the situation that App.TFoo <> Dll.TFoo. > > > > > > > > Borland fixed this problem when the add their BPL libraries (in Delphi > 5 > > >I > > > > think?), as these have the knowledge built in to allow then to > reference > > >the > > > > calling applications VMT's. > > > > > > > > Simple solution then it to use BPL rather than DLL packaging > technology. > > > > > > > > Cheers, Max. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Delphi mailing list > > > > [EMAIL PROTECTED] > > > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > > >_______________________________________________ > > >Delphi mailing list > > >[EMAIL PROTECTED] > > >http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _________________________________________________________________ > > Need more speed? Get Xtra JetStream @ http://xtra.co.nz/jetstream > > > > _______________________________________________ > > Delphi mailing list > > [EMAIL PROTECTED] > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
