>On Fri, 2006-08-11 at 14:05 -0700, reinux wrote: >> Now the problem is this: if nearly all of .NET 2.0 is portable,
>...which is incorrect... It is portable enough to be functional - without COM, without WinForms, without EnterpriseServices. You're missing the point here - if any crucial changes are made in 3.5 that rely on 3.0, all subsequent versions will no longer be portable. Also, you've trimmed out a crucial point in my message: the _whole_ of .NET 3.0 is incompatible. >To be insanely literal, everything outside of ECMA isn't necessarily portable, and ECMA doesn't contain much (~250 classes, IIRC). That is insanely literal. You'd expect the Mono project to be abandoned if everyone worried about that. >LINQ is supposed to be a very generic framework. Generic enough to >work for arbitrary object graphs (IEnumerable), System.Xml, and System.Data. >I would like to see how they could make LINQ depend on something as specific as Avalon & Indigo, while still permitting it to be generic enough to work with what they've said it would work with. (I seriously doubt that it could be done in any rational manner.) LINQ may be safe. However, just having an anomaly in there of such size raises the risk and the _perception_ of risk enough to scare people away from the framework altogether. Sure, WinForms and such aren't portable, but are those areas on which newer technologies will be built, as will undeniably be the case with WCF and WPF? >This doesn't mean that other features couldn't be introduced that >depend on the newer WinFX libraries, but even if WinFX isn't termed ".NET 3.0," does that really change anything? Really? >If they _don't_ call it ".NET 3.0", they'd instead require that your future applications depend on both ".NET 3.0 w/o WinFX" + WinFX -- i.e. you'd need two dependencies instead of just one. And nothing stops them from making ".NET 3.0 w/o WinFX" from depending on WinFX (as a circular dependency). If you've seen Vista's development with trying to build a huge chunk of the OS on a non-existent API, you'd see that circular dependencies while they may sometimes be tried, they will be less likely. Think WinFS and its setbacks before it was abandoned. The reason isn't technical but it's still simple enough: development schedules and team structures. We aren't talking about just software here - we're also talking about business. And yes, most of Microsoft's future software will probably require both WinFX and .NET. However, that is much better than risking everything requiring both as well. It'd be ridiculous for people to need to say "Requires .NET 2.0 Framework but not .NET 3.0" or "Requires .NET 3.5 Framework but not .NET 3.0". >There are _far_ better things to spend your energy on. The naming of WinFX is quite inconsequential, and was done primarily to keep the dependencies sane for ISVs (only one dependency to install, not two) and marketing purposes (to kill the "WinFX is going to replace .NET!" insanity from those who really don't know any better). Of course. Technically it has no effect for now. I spent all this energy knowing that it all boils down to marketing, and better marketing is what I'm arguing for. It's not entirely technical; perceptions can change on the part of Mono devs and users, and worse, they can also change within Microsoft itself. Then it'll really become technical. Thanks for the feedback, Rei -- View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5789173 Sent from the Mono - General forum at Nabble.com. _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list