[fpc-devel] Packages, Generics

[Marco van de Voort]

In our previous episode, Willibald Krenn said:
> > No it won't. Not all of the implementation of a package needs to be in the
> > .BPL equivalent. Neither is the case in Delphi. 
> > 
> > Seek for $weakpackage and read the packages wiki again
> 
> In words of Borland/Embac - "Unit files containing the {$WEAKPACKAGEUNIT 
> ON} directive must not have global variables, initialization sections, 
> or finalization sections." Which makes sense. So not putting something 
> into the bpl comes at a cost.

No, it comes with limitations. 
 
> Also, I don't see the benefit of trying to introduce packages to have 
> each type defined only once within the project, except that all generic 
> types (and descendants thereof) would be spread all-over again.

That's where generics are special. The code is generated on the spot where
they are specialized, not on the spot where they are defined.

If you want to avoid that for space reasons, specialize a few common cases
in the BPL, or, if it is a system BPL, in a secondary BPL.

> > So in short, everything in the units that doesn't go into the DLL goes into
> > the .DCP which is more or less a dcu archive if I understood it correctly
> > 
> > So only the specializations used inside the code contained in the BPL (and
> > maybe one or two that you could force to save duplication) are in the BPL.
> > 
> > So in short, the problem is one that you create yourself by self-inflicting
> > that every piece of code _must_ be in the BPL. That isn't the case.
> 
> Ok, so lets say one of my generic classes uses class variables (static 
> fields). Duplicating the type in each package defeats the purpose of the 
> package-concept to have one common type across all modules of a running 
> application.

No, since any specialization creates the actual types, and they all will
have their respective static fields anyway?  (since the static field can be
of the variable type)

There are some languages/runtimes that have some damage control here (most
notably C# which uses constraints to limit the definition to classes
implementing a certain interface, and it is said to typically share
specializations for such classes)

> Say I have a generic TMyList<T> type with some class variable. Then, I 
> use the specialization TMyList<TMyOtherClass> in two different packages 
> that depend on the package where TMyList<T> was defined. As soon as 
> TMyList<T> is put into the .dcp, it will be statically compiled into the 
> two other packages - hence you end up with 2 "instances" of the same 
> type, which leads to having 2 different versions of the class variable 
> (and N in the general case). 

Fully correct.

> In my opinion this is not what packages are 
> about.

Well, what can I say about that?

> Packages are a means to transparently break your application in 
> to modules.

True, the specialization is what generates the code AND THAT IS NOT IN THE
UNITS IN THE PACKAGE! So the logic still holds.

> BTW: It would be intersting to know whether Delphi allows 
> some sort of "type TMyNewList<T> = type TMyList<T>" definition  which 
> would create a new type with a different set of class variables.

You can try, but I doubt it. The = type <x> functionality is mostly
sleeping, in both FPC and Delphi.

> Finally, I have to confess that I am absolutely clueless about the 
> semantics of class variables in FPC's generics. Most probably FPC only 
> shares class variables between all instances of the same "type mySpec = 
> specialization TMyList<...>" type,

That's what I expect yes.

> which would give somewhat room for the .dcp implementation.  But this is
> not the usual semantics of generics.  It also is not the Delphi semantics
> of generics, I suppose.  This is (C++) templates without header files.

As far as I know, it is this way for any compiled language.

The only exception I know is C#'s constraints, but that is possibly nothing
but a bit of damage control in a totally different environment.  Still it
might be possible for FPC too, but that is a totally different subject.

When I read up about the C# stuff I didn't know that much about generics
yet, so if interested, I encourage you to do your own research. But don't
get your hopes up too much.