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 <xhaj...@hajny.biz
<mailto:xhaj...@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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal