[fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

Maciej Izak hnb.code at gmail.com
Thu Jan 28 12:52:14 CET 2016

2016-01-28 11:34 GMT+01:00 Sven Barth <pascaldragon at googlemail.com>:

> The format of interface VMTs could also differ per platform so considering
> that as more stable only holds true because of what we currently support.
That is very easy to adjust.

> The more stable approach would definitely be the one that does not rely on
> implementation details, but only on the specified, documented language
> behavior (bugs not withstanding of course), thus the approach I've
> mentioned above.
To be clear maybe is time to documenting this.

> I consider the approach with manual interfaces as hackish. Period.
> Nevertheless if I don't find anything else that sparks my worries I'll
> probably commit it anyway... However on the first sign of a breakage (in
> the part that's related to the manual interfaces) that's not because of a
> newly introduced bug I'll disable them and won't care about them anymore.
There is one big advantage in manual interfaces - less RTTI trash. Other
approach will potentially brings ~100 additional useless classes or even
more, It depends on the manner of implementation (for example is possible
100 classes per hashing or (!) even more - it can potentially mean few
thousands useless classes). Maybe is possible to reduce this by using
"implements" keyword or by this language feature (redirecting interface
method implementation to other method): "function IFoo.Foo =

(!!!) I don't know whether a different approach is implementable
(especially because we have multi hashing, on the other hand in few places
generics relations are complicated). If we decide to use other approach (if
it is possible) than manual interfaces, it will brings other hack IMO much
more "hackish" (fake interface casting) and it potentially/additionally can
generate many trash classes.

> Speaking of breakage... Do you have tests that could be run together with
> our testsuite? They need to be named t*.pp and need to return an error code
> of 0 on success and anything else on error. They can make use of fpcunit
I have inner tests especially for dictionaries (thanks to FPC generics we
have many kinds of dictionaries :O). I will adjust the tests when you
decide to commit library.

Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20160128/4f5919d4/attachment.html>

More information about the fpc-devel mailing list