Menu
▾
▴
eclipsedotnet-developers
|
From: <jpp...@gm...> - 2005-11-26 18:32:12
|
Damn. I just noticed a huge typo in my previous mail. When I said "Putting the platform back to 1.1 should be too difficult.", what I meant to say was "Putting the platform back to 1.1 shouldn't be too difficult.". Amazing how 3 teeny weeny characters can screw the meaning of a sentence altogether... :\ Sorry for any misinterpretations. JS -----Original Message----- From: Jo=E3o Saraiva [HYPERLINK "mailto:jpp...@gm..."mailto:jpp...@gm...] Sent: s=E1bado, 26 de Novembro de 2005 15:31 To: 'ecl...@li...' Subject: RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again That's a good point. Eclipse.NET really isn't using anything special in = .NET 2.0 as of yet (except for Generics ). The reason I recently migrated the platform to 2.0 was because this = would have to be done eventually, although I admit that I might have been = hasty in this matter. Another reason was the redefinition of the Eclipse.NET GUI = to be based on SWF rather than SWT, and SWF 2.0 offers some enhancements = over the previous version (from what I've read: new controls, previous = controls expose some more properties from the underlying Win32 controls. Also, = one very cool feature is LayoutManagers; it appears Microsoft has finally = come to its senses and looked at Swing, instead of just looking at Java's = class library). But, since this new GUI will take some time to be developed, = there is no really good reason for the platform to adopt .NET 2.0 right now. Putting the platform back to 1.1 should be too difficult. The only thing from 2.0 I'm using is Generics, and that's nothing a thorough search for "using System.Collections.Generics;" and some patience can't take care = of. However, in defense of 2.0 and from what I've been seeing/reading, using generic collections is faster (not to mention less error-prone) than = using "normal" collections (and, considering the implications of = boxing/unboxing when using these "normal" collections, I don't find that hard to = believe), although I'm a bit skeptic regarding the values that Microsoft provides = (2x faster for collections using reference types, and 3x for value types). All that said, I am not sure about what position to take regarding this subject. David and Rui, what are your thoughts on this? JS=20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: = 25-11-2005 =20 |
|
From: Kunle O. <kun...@vi...> - 2005-11-30 02:12:18
|
> OK, nothing more is coming to mind right now. Please complete=20 > this list as much as possible. Seems complete. > Meanwhile, I'm taking a look at the SharpDevelop IDE too, as=20 > a possible replacement for Visual Studio. Maybe the answer=20 > could be lying in the change of the IDE, instead of changing=20 > the .NET framework. Not really. We just have to decide and bite the bullet. We don't *need* = .NET 2.0 (or C# 2.0) to build the platform but, we might prefer to target it anyway if it boosts our productivity for instance. Kunle |
|
From: <jpp...@gm...> - 2005-11-30 11:05:07
|
> Not really. We just have to decide and bite the bullet. We don't *need* > .NET > 2.0 (or C# 2.0) to build the platform but, we might prefer to target it > anyway if it boosts our productivity for instance. Agreed. Frankly, I tend towards picking .NET 2.0, not because of the IDE or because of Generics (the parts of the platform that use generics can be easily adapted to use normal collections, it's just a matter of 1 or 2 days' work, as I previously mentioned), but because the .NET 2.0 framework can load .NET 1.1 assemblies. So, if one has plugin dlls made in 1.1, those can be used without problems. The opposite (.NET 1.1 using 2.0 assemblies) is not true, and forces the developer to use 1.1 (most shouldn't find that a problem, but there may be cases that do). However (and this just came to my mind right now), this "advantage" can turn out to be a disadvantage: if the platform assemblies are made in 2.0, developers that (re)compile their assemblies must use the 2.0 compiler (not the 1.1). The reason is that the compiler will need to access referenced assemblies in compile time, and so it must be able to load those referenced assemblies (in 2.0). And, on a personal opinion, I do think that .NET 2.0 (especially generics) can greatly improve developer productivity. Just yesterday, I corrected some bugs (in the SWT_UI solution) that would never have gotten there in the first place if I had generics when I first made the code :( . BTW, the preferences dialog should now show all pages without throwing the infamous "There was an error alerting a preference listener." :D . But VS2003/2005 can still be a big pain in the butt. That's why I have in my next TODO tasks to take a deep breath and look at Nant, to add the scripts to build the assemblies (therefore bypassing VisualStudio and removing the need for it). JS |
|
From: Rui S. <rmt...@gm...> - 2005-11-30 11:30:22
|
There are some factors that may influence our decision, I will talk about these: - Productivity - Marketing In the productivity field, we are worried if the adoption of the .NET 2.0 is what we need to increase the development of the tool. The major advance I see here, is that VS2005 is a big improvement over VS2003, and it can really increase our productivity. As a drawback of switching to VS2005, we cannot use .NET1.1 . Today, the major improvements in the development cycle arrive from the use of a good IDE, and not from a small set of features introduced in a new version of a language. Another force that we have to deal are the libraries, in this domain I haven't the knowledge to express an opinion. Another thing we have to take into account is Marketing, we should think about what platform our users are using and if they are able to switch to the new platform? About this, I have to say that almost everyone will make that switch, because microsoft and mono are motivating the users to do that. Rui |
|
From: <da...@me...> - 2005-12-01 12:52:48
|
Hi! I think that the best for the project Eclipse .NET is to integrate and explore .NET 2.0 framework?s functionalities as soon as possible. It is not a question of following the high tech hype. As my other colleagues referred, it?s a matter of recognizing the benefits that this framework brings to the developer in terms of C# 2.0 and the productivity gains by using VS2005. Despite that I?m not using currently these in my prototype, I?m planning to integrate them soon. Besides that, if the hole community (Microsoft and Mono Project) is making the change I thing that resisting to .NET 2.0 is contributing for Eclipse .NET to become outdated. Jo=E3o has already made some changes not because the hype but especially for his own profit in terms of developing facilities. He also had the determination to reason carefully about what you said and presented us with a detailed logical explanation that convinced me more about the need of this change. For me integrating .NET 2.0 is for the best. Besides no one likes to ?pass from horse to donkey? this is a bad translation from a Portuguese saying, but I think you?ll understand ? Best regards, David Ferreira |
|
From: Kunle O. <kun...@vi...> - 2005-12-02 03:55:29
|
> Hi! Hi David, > I think that the best for the project Eclipse .NET is to=20 > integrate and=20 > explore .NET 2.0 framework?s functionalities as soon as=20 > possible. It is=20 > not a question of following the high tech hype. You are right of course. I see improvements to the AppDomain bits (particularly cross-domain = calling performance) as important given our framework of loadable/unloadable = plug-in architecture. > As my other colleagues referred, it?s a matter of recognizing the=20 > benefits that this framework brings to the developer in terms=20 > of C# 2.0=20 > and the productivity gains by using VS2005. Despite that I?m=20 > not using=20 > currently these in my prototype, I?m planning to integrate them soon. >=20 > Besides that, if the hole community (Microsoft and Mono Project) is=20 > making the change I thing that resisting to .NET 2.0 is contributing=20 > for Eclipse .NET to become outdated. Yep. > Jo=E3o has already made some changes not because the hype but=20 > especially=20 > for his own profit in terms of developing facilities. He also had the=20 > determination to reason carefully about what you said and=20 > presented us=20 > with a detailed logical explanation that convinced me more about the=20 > need of this change. Welcome to the dark side ;-) I'm drifting back to my original position that .NET 2.0 is cooler than = warm tequila. > For me integrating .NET 2.0 is for the best. Besides no one likes to=20 > ?pass from horse to donkey? this is a bad translation from a=20 > Portuguese=20 > saying, but I think you?ll understand ? Yeah, I can imagine. Proverbs are short sentences drawn from long = experience so, I concur. Let's ride the horse and lose the donkey. Kunle |
|
From: Kunle O. <kun...@vi...> - 2005-12-02 04:07:32
|
Hi Rui, > There are some factors that may influence our decision, I=20 > will talk about=20 > these: > - Productivity +1 I can't argue with that. Switching to .NET 2.0 does offer some nice productivity benefits not least is the fact that MS's IDE now offer refactoring out-of-the-box and, VS.NET project files are now MSBuild = files that can [probably] be used as is with CI systems like Draco.NET and CruiseControl.NET. > - Marketing +1 Hey look guys, we are using the coolest and the newest!. Join us and you = can too! ;-) Seriously though, there's a good vibe around Whidbey - C# 2.0, VS 2005 = and .NET 2.0. I'm back to believeing that it would be a shame not to tap = into it. Kunle |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X