<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-05-25 16:10 GMT+02:00 Tomas Hajny <span dir="ltr"><<a href="mailto:XHajT03@hajny.biz" target="_blank">XHajT03@hajny.biz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I assume that the functionality added to trunk (and as far as I remember<br>
also announced in the list) was finished to the extent that it works and<br>
may be used (although with some possible limitations), otherwise there<br>
would be no sense in adding it to trunk at all. As such, it's as supported<br>
as any other part of FPC (i.e. bug reports and feature requests may be<br>
created, etc.). If it doesn't work and noone can fix it, it might be<br>
removed (as with any other unfinished and not working feature), but I<br>
don't have any information about this. Could we focus the discussion to<br>
real problems, if necessary, rather then speculations?<br></blockquote><div><br></div><div>Sorry if any part of my message sounds like speculation. Is really hard to say anything without communication with core team (almost no communication - just ban). I was asking/talking in more private or public places but almost no one was interested to write any concrete reply.</div><div><br></div><div>I am always trying to act like professional, sometimes it is hard :). For sure removing MO from trunk is not good for me and means more work on my side for NewPascal, but the main goal of MO was introduction of smart pointers, nullable types and simplified ARC objects. Also in this context FastRTTI is very important, more extensive usage of smart pointers/nullable types/arc objects mean much faster final code. Every element is related: FastRTTI , MO and all smart pointers variants. So removing MO from trunk has sense if FastRTTI is not finished or smart pointers are not planned in near time.</div><div><br></div><div>If any of the core member is interested to finish this (FastRTTI, smart pointers, etc) I will be very happy, finally core has many more talented programmers than me. If someone other will finish this I will be happy too (finally the end effect will be good or even better for whole community).</div><div><br></div><div>Also the good solution may be to remove temporary MO from trunk, I can finish this in NewPascal (maybe I will be able to create more end-user friendly form, so temporary may be good to not break backward-compatibility) and we can talk how to merge things back.</div><div><br></div><div>I am always opened to any cooperation. For less frustration for both sides would be good to keeps both projects alive. I can continue NewPascal with my ideas and vision but at the same time I see no reason why FPC should not benefit from my work in less "neuralgic" code parts. If the core will change opinions about new features from NewPascal (I can also change any features or re-implement any of feature if FPC core wish that) any of feature can be merged back into FPC trunk. IMO this path is beneficial for all. In the worst scenario I will "burn out" (which is not planned by me) but in general FPC will be better.</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>