2018-02-05 15:00 GMT+01:00 Martok <list...@martoks-place.de>: > Why? ... >
Default property / field or/and aspects is better solution. The way mentioned by Sven with extending generic's scope means almost no control over used operators (or really hard to predict), IMO bad design >.<. Now we have a lot of problems with type/class/record helpers scope, for extending generic's scope I can guarantee "exponentially" more non-fixable problems + destruction of consistency of language and problems with implementation of default property / field and aspects... Pandora's box is nothing in comparison to extending generic's scope in such way :P. Simple example: specialization for the same generic type can behaves in different way! for example final code for TFoo< TSomeArray> will be different than for TFoo<TSomeArray> declared in other module (!). What if TFoo<T> has some class var + class constructor ? What if inside is used some dictionary (declared as class var and handled in class constructor/destructor) to handle different specializations (where as key of that dictionary is used TypeInfo(T)) and some logic is hidden behind of type which behaves in different way for the same specialization? Totally nuclear destruction and non-fixable problems for language and libraries. I will repeat it again : definitely non-consistent and destructive feature. This can't work in proper way. > * use Generics.Collections > I'd like to stick with fcl units, and rtl-generics seems pretty outdated > compared to your repo? > I'am working on Generics.Collections 2.0 it is not ready for trunk yet (anyway https://github.com/maciej-izak/generics.collections is full functional for 3.0.4 and trunk - just few tests are missing and part of interface for T*AVLTree*<> types). Generics.Collections 2.0 is much improved, with many fixes, full of tests and ready/optimized for Smart Pointers / Nullable types. I found also many new compiler bugs related to generics types and I want to try to fix part of them before I decide to update rtl-generics. -- Best regards, Maciej Izak
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
