> 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. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
