[fpc-pascal] Management operators question

[Alexander Grotewohl]

I don't really know why this NewPascal stuff is on this mailing list.


On 05/25/2018 11:59 AM, Maciej Izak wrote:
> 2018-05-25 16:10 GMT+02:00 Tomas Hajny <XHajT03 at hajny.biz 
> <mailto:XHajT03 at hajny.biz>>:
>
>     I assume that the functionality added to trunk (and as far as I
>     remember
>     also announced in the list) was finished to the extent that it
>     works and
>     may be used (although with some possible limitations), otherwise there
>     would be no sense in adding it to trunk at all. As such, it's as
>     supported
>     as any other part of FPC (i.e. bug reports and feature requests may be
>     created, etc.). If it doesn't work and noone can fix it, it might be
>     removed (as with any other unfinished and not working feature), but I
>     don't have any information about this. Could we focus the
>     discussion to
>     real problems, if necessary, rather then speculations?
>
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> -- 
> Best regards,
> Maciej Izak
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20180525/9dcffa56/attachment.html>