[fpc-pascal] Operator overload resolution with arrays

Maciej Izak hnb.code at gmail.com
Mon Feb 5 15:49:33 CET 2018


2018-02-05 15:00 GMT+01:00 Martok <listbox at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20180205/946c2946/attachment-0001.html>


More information about the fpc-pascal mailing list