Indeed. Good comments. Infact, after thinking about it a bit more I suspect we are going to have to redesign parts of the plugin mechanism. As you hint at, we are defeating our own reason for not using BPLs by relying on class comparisons anyway (to then access class properties). We won't switch to BPLs but will have to redesign what we are doing so that class comparison (followed by accessing properties) is not necessary.
Cheers, Phil. ----- Original Message ----- From: "Max Nilson" <[EMAIL PROTECTED]> To: "'NZ Borland Developers Group - Delphi List'" <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 3:11 PM Subject: RE: [DUG] Passing Objects to a DLL > Phil Middlemiss said: > > > Good idea, although I'm not so worried about speed. Comparing > > class type names may be slower, but it is certainly easier to > > code than to build up a VMT translation table! Still, I'll > > try and remember that idea in case of later development needs. > > If its one thing we do not have a shortage of at this time is CPU power. > Using a few cycles comparing two strings is not going to cause much of a > slow down at all, and if it does this would indicate that the code in > question is using far to many class type interogation and should be > redesigned. > > I've been thinking some more about the versioning issues you had with bpl's, > and while I realise that this would be a serious problem for a distribution > of your size, Borland did not do things their way with a very good reason. > > By assuming class matchs based on the names stored in the VMT's (ie. the > class name) you are taking it upon yourself to guarentee that there will > never be any mismatches between the VMT in the application and that in the > plugins. I can see that if you are not extremely careful about versioning > you could end up with some very hard to debug situations were the actual > class did not match. > > In fact this entire object versioning mess is exactly what COM was invented > to try and avoid (see "Inside OLE2" for more on this). As you said Borland's > BPL technology satisifies the basic portion of the shared objects in > separate files problem, but cannot handle the versioning issue without a > full recompile. COM handles it perfectly at the expense of having to cater > for a serious sick history of backwards compatibility. > > Without looking further into exactly what you were doing, and how and why I > can't make any judgement about wht you should do to improve the situation. > It's the sort of architecture vs pramatism problem that can cause my pain in > an company. > > 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
