<p>Am 28.01.2016 01:14 schrieb "Maciej Izak" <<a href="mailto:hnb.code@gmail.com">hnb.code@gmail.com</a>>:<br>
><br>
> 2016-01-28 0:38 GMT+01:00 Sven Barth <<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>>:<br>
>><br>
>> Why would each collection instance need to contain an instance of the comparer? They don't contain state and are reentrant, so they can be easily shared with ARC singletons.<br>
>><br>
>> Note: there would either need to be a global variable for each instance or a list that gets automatically finalized as well (e.g. as a stupid implementation an array of IInterface). Then if Generics.Defaults is finalized before the other unit using it only the reference count will be decreased and only when the other unit is finalized the comparer will be destroyed.<br>
><br>
> Yes it can be done in that way, but I want to avoid this (It will complicate other things). In Generics.Defaults manual interfaces are easier to maintain. Manual interfaces are more solid construction. They are more resistant for improper use than regular ARC interfaces. You did not specify any technical argument to discrediting manual interfaces implementation in Generics.Defaults. Just a feeling :P. Your only technical argument has been overthrown.</p>
<p>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.</p>
<p>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.</p>
<p>I consider the approach with manual interfaces as hackish. Period.</p>
<p>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.</p>
<p>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 AFAIK.</p>
<p>Regards,<br>
Sven</p>