[fpc-devel] generics

[Peter Vreman]

> hi,
>
> Am Freitag, den 29.04.2005, 21:48 +0200 schrieb 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 >.
>
> characters < and > have no meaning with a type as operand, correct ?
>
> So if its only for that, a special section isnt really required.
>
> A possible reason for separation is that you _need source code for
> generic types_ to use them, which is obviously not the case for normal
> types.
>
> So choices now are:
> a) add generic interface section, generic implementation section
> b) intermix them in the normal sections, with the only difference being
> "if '<' follows typename, its a generic type"
>
> So the next part to decide on is how to actually implement
> specialization.
>
> I've been thinking: define type parameters to actual types, with them
> defined compile the generic source code into new object file
> (genericunit-typeparameter1-typeparameter2.o or something).
>
> Comments?

Handle it like a macro with a parameter. That is much easier to implement.
Creating new modules/objects is much more complex.