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
