[Mono-dev] gmcs and The Future

Евгений Гришуль eugeny.grishul at gmail.com
Wed Feb 4 07:55:53 EST 2009


Hi,

gmcs Compiler already not 100% compatible with csc -
__arglist<http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx>,
__refvalue <http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx>,
__makeref <http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx>not
supported ( it can significatly reduce P/Invokes in bridging code of
NObjective <http://code.google.com/p/nobjective/>)
"reflect" is great idea for refactoring but may be better to call it
"__memberinfo" =)?

2009/2/4 Jb Evain <jb at nurv.fr>

> Hey,
>
> On 2/4/09, Scott Peterson <scott at ssblack.co.nz> wrote:
> >  Mcs has done an excellent job of tracking the official C#
> >  language, and it will continue to do so, but the Mono project has a
> >  world-class compiler entirely at its disposal. We need not confine
> >  ourselves to the blessed specs of Microsoft or Ecma. We could "trick
> >  out" C#, indulging in sugars of our own device, so long as we keep our
> >  creations in -langversion:future. Those projects which are willing to
> >  sacrifice compatibility with csc in order to partake of our forbidden
> >  fruit can write code in this New C#. This C#++. This
> >  -langversion:future.
>
> I'd be very cautious with that idea. I've been told enough that mcs is
> a `production` compiler :)
>
> I mean, sure it's fun to experiment language changes and improvement.
> But who decides what will go in and what not? And when it's in, who is
> going to maintain it? Most people that will work on a patch for the
> fun of it won't maintain the feature for a long time. If it's
> perfectly ok for a feature that is needed, or for some libraries, it's
> not really the case of mcs. Then it triggers some questions, like what
> if a change to the parser (or some place else) for a `future` feature
> gets in the way of a fix for the normal version of mcs?
>
> Anyway, am not completely against the idea, I already wrote about how
> I'd like to have a more extensible mcs, but in the current state of
> affairs, again, I'd very cautious.
>
> --
> Jb Evain  <jb at nurv.fr>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



-- 
WBR,
Eugeny Grishul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090204/4945900a/attachment.html 


More information about the Mono-devel-list mailing list