[fpc-devel] Packages, Generics
Marco van de Voort
marcov at stack.nl
Sun Sep 12 22:03:50 CEST 2010
In our previous episode, Willibald Krenn said:
> > 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)
> Played around with Delphi today, and it seems that class vars are
> somewhat broken on generic types. They work as expected (share common
> class value amongst all sameclass<sametype> instances) only in a unit
> scope, it seems. Which is a pitty.
To be honest, that is already more than I expected.
> since the '+' operator is not defined on T.
Generic versions of Delphi have operator overloading? Or did I miss
> Delphi lets you constrain your type parameters. That said, I don't really
> understand why constraints like :integer, :TObject are not allowed.
Does C# actually allow that? I thought it only supported interfaces?
> (:record, :TMyClass are perfectly fine.) So Delphi's generics are more on
> the C#/.NET side than on the C++ template side.
Well, when they were developed, Delphi.NET was just being canceled, so that
is no suprise.
> Uh, no need to shout. I understand what you are saying, however, I'd
> still prefer to have working class variables,
Personally I only am interested in the constraint for object types. Many
generic container types operating on objects only improve typing, and thus
are runtime empty.
Mapping them onto eachother makes .exe's and memory footprint smaller, and
more importantly, might have an effect on caches.
The opposite constraint (that excludes inheritable types) could maybe be
useful for optimizations.
> rtti checks etc. even with generic classes and packages.
You'll have to explain that in more detail. I fail to see the connection.
Moreover, this is turning into a generics feature and wishlist discussion,
while it was about packages.
> > You can try, but I doubt it. The = type <x> functionality is mostly
> > sleeping, in both FPC and Delphi.
> Tried it: not allowed.
No surprise there.
> > 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.
> Well, IIRC Eiffel, Java/Pizza, .NET, Delphi all support constraints on
> type parameters. .NET actually has quite good support for generics (Java
> is limited in that respect).
Java and .NET also is a JIT who can delay certain things till runtime, when
all loaded parts form a single program over which the JIT has more or less a
complete overview. IMHO interesting for ideas, but not for implementation.
Delphi has constraints, but they don't reach your goals. So maybe it is time
to stop the comparison game, and describe how you think such features should
> Ok for the start I'll be looking at co/contravariance, and lambda
> functions ;-). Joke aside, I'll think about the .dcp idea and how this
> might work out with packages.
.bpl : a DLL with some runtime stuff.
.dcp : everything else,
- the .ppu like information for everything in .BPL (since the
.bpl/.exe split is arbitrary, the compiler has full control,
so it must be in there)
- code that didn't go into the .bpl (weakpackaged, maybe even
complete units, but also stuff to construct tables needed
in the main program)
- everything not linkable, inline functions, generics etc.
More information about the fpc-devel