Linq would be the biggest thing. The reason being, when devs begin to
get very serious with new things like this, mono users are screwed…
On Sun, Mar 23, 2008 at 12:54 AM, Michael L.
<[email protected]mailto:[email protected]> wrote:
I think the primary concern would be with C# 3.0 features that the
mono compiler does not support, i.e. Extension Methods, Lambdas,
Linq… Though I know they’ve been working towards support.
Secondary concerns would be .NET 3.0+ libraries that Mono hasn’t
implemented yet. Right now (well as of Rev 77) I can compile IronRuby
on mono in Linux, don’t want to loose that.
In any case, there will be an interop question to answer here. I think
we can assume .net will always be x number of features ahead of mono.
Being a .net developer by day, interop with .net would be more
important for me. I’d love for ironruby to be able to support all of
my .net artifacts no matter when we upgrade. I’m sure plenty of people
in the list will think mono support is more important to them.
I’m wondering how possible it will be to support both scenarios by
mixing in the different language constructs when needed.
I realize the interop stories haven’t been given much thought yet, but
the earlier this dialog is started the better off the implementers
will be when its time to hit the road.
On Sun, 23 Mar 2008 11:55:11 -0600, John L. (DLR) [email protected]
wrote:
Last time i talked to Miguel, he said that they were done implementing linq modulo bugs.
The most recent release (1.9) contains a HUGE number of improvements
to both their C# 3.0 feature support as well as LINQ-related feature
support. Though quite obviously they exist somewhere in the feature
chain, as of this date I have yet to run across any compilation or
runtime issues between .NET 3.5 and Mono 1.9, though I’ve only recently
(as of the last 3-4 months) started taking full advantage of both in the
Nuxleus code base (which covers a fairly large swath of the FCL.)
That said, if there’s one thing that’s been proven more times than I am
both willing and able to count it’s that the Mono Project developers are
constantly driven by the challenge to ensure the DLR and related
projects are able to both compile and run against the Mono assemblies.
In other words, sometimes the best way to get something fixed is to
highlight the fact that it’s broken. Pushing the envelope via using
some of the more alluring features and functionality of both C# 3.0 and
.NET 3.0/3.5/LINQ is certainly one way to find out what works and works
well and what is in need of attention.
