Fundamentally, I agree as well. <g>

Everything in the framework should be accessible to all languages - however, another truth is that each product team has a finite set of resources, and each has their own community that prioritize feature sets differently. So, each team has to prioritize their work accordingly. Therefore, you may find one team doing something before another, or them doing the same thing together.

Also, the IDE usage of the two languages may indeed differ. We can auto-case stuff, C# can't because of case-sensitivity. That's a simple example, but a true one.

Another example - VB implements language features like CStr and CInt (converts to string or integer). The framework provides the Convert object which can do the same. There's a difference, however, the VB language functions automatically handle locales for you - so they know how to deal with differences in showing currency, etc. In fact, in these cases, since CInt(), for instance, converts to IL directly, it can actually be faster than Convert (strange but true).

Dim L As Long : Dim I As Integer = Convert.ToInt32(L)

is actually slower than

Dim L As Long : Dim I As Integer = CInt(L)

Of course, I've always said that it's a rare business app that you have to worry about every millisecond, but I don't see the C# team necessarily deciding to create new functions in the language that handle locales and generate down to IL when the framework allows you to do it yourself.

yag


>Fundamentally I agree.
>
>However, we've all seen how things really work at Microsoft <g>... There's a lot of competition and pride between the teams and while there's nothing wrong with that it sometimes gets in the way of providing a) consistency across the tools (only too obvious if you look at various .Net implementations - Winforms vs. Web Form syntax to state a really obvious example) b) potential features that could benefit the entire .Net platform or VS.Net environment.
>
>I've stated my preference on this to you a few times: If there's a chance to implement something in a language neutral way then it would be of the biggest benefit to the developer community at large to implement it as such and not put into one of the languages. Whether that's integration directly into the .Net SDK or as some sort of add-on is not really important as long as the concept of common operation is at least a priority.
>
>I realize that this may not always be possible and there maybe things that require tweaking the language itself, but I honestly think that almost any 'feature' that one could wish for could be implemented on a common level rather than on a language specific level. At this point of object orientation and objectification of most developer tools it makes little sense to extend languages unless we're talking of doing something like adding a native DML to a language. <g>
>
>IDE features, too. I think it's kind of silly that C# and VB do this differently. If the same approach was used common tools could be used to generate help files for example from the XML documentation. Now - you have to do two different things to use that stuff. That doesn't make sense...
>
>But with IDE integration i can see that languages could part and provide sepearate benefits, but this mostly takes the form of code generation in one for or another which while useful is not something one can work around with.
>
>+++ Rick ---