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? cheers, Danny -- www.keyserver.net key id A334AEA6
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
