<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-01-28 11:34 GMT+01:00 Sven Barth <span dir="ltr"><<a href="mailto:pascaldragon@googlemail.com" target="_blank">pascaldragon@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><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.<br></p></span></blockquote><div>That is very easy to adjust.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><p></p></span>
<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></blockquote><div>To be clear maybe is time to documenting this. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div>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 = SomeOtherNameThanFoo"</div><div><div><br></div></div><div>(!!!) 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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div>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.</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>