> > 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...
"Solution 2" is not really trivial. It will not work if 2 classes share the
same name but are different. Eg., I can create a TMenu class in unit X and
pass that to the DLL. It will not be able to tell if that class is TMenu
from the VCL or my TMenu class.
> What are the pros and cons of packages...
Pros:
1. You get all the benefits of DLLs (eg. dynamic loading), but with
Delphi's object model extended across application / DLLs.
2. Ease of Extensibility, eg. Delphi's design time packages - this requires
that your interfaces are well designed.
3. Memory sharing - common classes are loaded ONCE and shared, resulting in
lower memory requirements.
4. Significantly faster compile and link times.
5. Easier to split the project into several programmers, each working on a
package.
Cons:
1. All packages MUST have unique unit names. I.e., unit name space is
global.
2. You must compile your app to use packages.
3. You distribute several files (eg. VCL compiled package files) as opposed
to one - and this can lead to "versionitis".
4. If you fix a bug in a unit belonging to a package, and you forget to
recompile the package, you can waste a lot of time trying to track down an
already fixed bug.
> I understand that
> packages introduce a
> fairly heavy memory overhead - is this true for compiletime
> and run-time packages?
It is all relative. Sure, using packages will increase the memory
requirement of ONE application, and you don't generally see an improvement
until you start to run several applications. However, the memory overhead
of packages is smaller than DLLs, so if you are prepared to use DLLs, memory
shouldn't be an issue.
Regards,
Dennis.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
