[fpc-devel] Delphi-like Packages, Plan

[Dimitri Smits]

----- "Marco van de Voort" <marcov at stack.nl> schreef:

> In our previous episode, Willibald Krenn said:
> > > I don't like the Delph all-or-nothing philosophy here. I'd prefer
> to
> > > specify the packages, that shall be loaded at runtime, while all
> other
> > 
> > You can always load packages at runtime.. That is, after the RTL 
> > supports that of course.
> 
> Runtime loading of loading is quite a different process from startup
> loading, and only used for plugin system (where the baseclass is
> statically
> linked, and the plugins implement the baseclasses). Dynamic loading
> for
> enormous amounts of symbols might be costly (since they are resolved
> with a
> call per symbol, instead of by one call to the system, as during
> startup).

only the symbols that are used are imported in the dyn-loaded package. And it exports all publicly available types/procs/consts/vars.

> 
> The KDE suites startup speed problems have shown that very
> complicated
> dynloading schemes are not desirable.
> 
> The RTL is always loaded on startup btw.

to say even more, when you run with runtime packages, it's units are initialized first (before any other units/bpl's/the main exe).

> > > packages can be linked into the executable. This would allow to
> use an
> > > minimal set of external modules, which are shared by the exe and
> the
> > > really self-contained packages.
> > 
> > What you probably(?) could do is to link all basic packages into the
> 
> > executable but still export all symbols, so that when the shared
> object 
> > is loaded it finds all necessary entry points.
> 
> Problem is that that leads to a dependancy circle (pkg->exe->pkg).
> Maybe not
> a blocker problem, but more a complication.
> 

when you use packages, it requires some discipline, that is right. Consider following scenario:

pkg1: your plugin-base classes, requires RTL package
exe: imports pkg1 as a runtime package requirement, statically binds the gui components in lcl/vcl since it was not defined as a runtime package link requirement
pkg2: a plugin for runtime loading, requires RTL package and VCL/LCL package

what would be result when you want to import this at runtime through a loadlibrary call?

I would suspect that you then have "duplicate units"-error. Compiler cannot defend against it due to the "runtime" information vs "compile-time" information. 

Just to show that packages bring their own set of problems and pitfalls. But definately not all is bad ;-)


> > However, at the moment I don't see why this is better than shipping
> all 
> > necessary ppl files. BTW: I realize that ppl might be a bad TLA -
> since 
> > it probably means "people" for quite a number of ppl ;-)
> 
> Nah. Just wonder if that is necessary, if Delphi .bpl's are not
> compatible
> too eachother anyway.

that is why versionnrs are included: RTL70.BPL (Delphi 7) vs RTL150.BPL (Delphi XE aka 2011)

kind regards,
Dimitri Smits