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