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 <j...@nurv.fr> > Hey, > > On 2/4/09, Scott Peterson <sc...@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 <j...@nurv.fr> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- WBR, Eugeny Grishul
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list