[fpc-devel] generics

[Peter Vreman]

At 18:06 29-4-2005, you wrote:
>Hi,
>
>Am Donnerstag, den 28.04.2005, 07:53 +0200 schrieb Peter Vreman:
> > > Hi,
> > >
> > > I'm trying to add support for generics (templates) to fpc.
> > >
> > > Do we want to have a "generics" section (like "interface",
> > > "implementation") or do we want a special source code type (like "unit",
> > > "program") in the source code ?
> > >
> > > I'm tending to a special source code type "generic unit".
> > >
> > > The generic source code file (.pas,.pp) is installed (not the .ppu,.o).
> > > Then in the 'uses' handler, when not finding a ppu, it reverts to the
> > > pas file, and then finds that it is a special source code "generic unit"
> > > or so, so it *doesnt* compile it right now, but 'uses' actually just
> > > registers the generic classes as 'available for compilation later'.
> >
> > You only need 1 generic type at once.
>
>I dont understand what you mean by that sentence. At once when
>attributed to what ? Need where ? Need how ? (uses, derivation, type
>alias, variable declaration, ?)

When you define an implementation of a generic class then you only need 
that generic class. It is strange to defer compilation of a complete unit 
with generic classes. And to allow only one generic class in a single unit 
is also very strange and sounds more like a hack instead of a real solution.



>I have a test maplist module with only one generic per unit (that the
>$DEFINE/type approach only works with one generic/unit might add to
>it ;)), if you mean that. I agree that multiple generic classes in one
>unit would be good. But mixing generic classes and non-generic classes
>in one unit isn't a must-have item, really.
>
> > Why should a complete generic unit
> > be used? Also using it as a unit is inconsistent with the way that units
> > are handled and will require a lot of if..then parts in the unit loading
> > code.
> > And that code is already one of the most complex parts of the
> > compiler. It is already on a after 2.0 todo list to be rewritten because
> > of this complexity.
>
>I see. Well, then lets do generics sections (like "interface",
>"implementation") (maybe "generics interface", "generics
>implementation" ?) or perhaps not separate them section-wise at all
>(that is, mix generic types and non-generic types in the unit as if they
>were the same; would be confusing, perhaps)

A generics section is the easiest to implement. The block_type in the 
parser can then be set to bt_generics and allow different meaning of 
characters like < and >.




Peter