> Aaron wrote:
> The biggest annoyance with the DLL idea is our dependance upon
> polymorphism through the 'is' operator... I haven't experimented with
> packages, but I understand this alleviates this particular problem...
> Yes, Packages fixes this but there other solutions. To understand why the
> problem is there, you need to understand how 'is' works internally and why
> that breaks with pure DLLs as opposed to packages which do some extra magic.
I know why it fails... This doesn't remove the fact that our application depends
far too much upon this working that it has (for now) stopped any investigation
into designing around a plugin architecture - shame really because it would
be a powerful bonus for us...
> 1) You can use packages. When Delphi introduced packages they added an extra
> level of indirection into the parent TClass VMT pointer chain. You can see
> this by comparing the pre-packages Delphi System.pas code with the current
> System.pas code.
> 2) Without packages, you can implement your own 'is' style operator which
> compares via _ClassNames_ (i.e. strings), not via TClass values (i.e. VMT
> pointers). This will succeed even across an EXE/DLL boundary. It will be a
> bit slower that Delphi's hand-tuned assembler VMT pointer version but it
> _will_ work.
Solution 2 is trivial but cumbersome...
What are the pros and cons of packages... I understand that packages introduce a
fairly heavy memory overhead - is this true for compiletime and run-time packages?
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
