[Mono-dev] gmcs and The Future

[Marek Safar]

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/>)
>
__arglist is fully supported.

We have not implemented __reftype/__makeref mainly because nobody raised 
any interested in these undocumented keyword. If you missing this 
support please fill a bug report.

Marek


> "reflect" is great idea for refactoring but may be better to call it 
> "__memberinfo" =)?
>
> 2009/2/4 Jb Evain <jb at nurv.fr <mailto:jb at nurv.fr>>
>
>     Hey,
>
>     On 2/4/09, Scott Peterson <scott at ssblack.co.nz
>     <mailto: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 <mailto:jb at nurv.fr>>
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> -- 
> WBR,
> Eugeny Grishul
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>