:
: My thoughts on this....
:
:
http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp
I've taken an opportunity to review the material (thanx to the OP for the
link) and I don't have the same reactions.
First, I should note that these changes do not apply to VB only. There is
also a link to the future of C# and I can't help but notice that the
features being commented on here are being included in both languages.
These
features are changes at the framework level and are not changes to
specific
languages. At least, that's my take.
Any down side to these changes will impact VB and C# equally and if VB
code
will become littered with bad code blocks, C# will be just as likely to
have
the same result. That said, I'm not so sure these changes will necessarily
produce bad code.
Here is the link to the C# document (Word .doc file)
http://download.microsoft.com/downl...5d0-ffe749822f1b/csharp 3.0 specification.doc
: My thoughts:
:
: 1. Regarding Implicit types, I don't use type declaration for the
: benefits of performance. It's for the benefit of clarity of purpose
when
: reading code. The first thing I do with neophyte developers is turn
: Option Strict On to help them understand why they do what they do. With
: this, I can't stop people from writing garbly gook.
I don't see where implicit typed local variables is a bad idea. What's
wrong
with the following?
Dim Title = "Dr."
Dim GivenName = "Joseph"
Dim OtherName = ""
Dim FamilyName = "Bleaux"
Dim NameSuffix = "Jr."
Dim NickNames() = {"Doc", "Joe", "Junior"}
Dim DateOfBirth = "UKNOWN"
Dim DateOfDeath = "UKNOWN"
Dim CauseOfDeath = "UNKNOWN"
We are clearly defining 9 objects of type String (including an array of
strings). As the documentation states, these are precisely equivalent to
the
following:
Dim Title As String = ""
Dim GivenName As String = ""
Dim OtherName As String = ""
Dim FamilyName As String = ""
Dim NameSuffix As String = ""
Dim NickNames() As String = {"Doc", "Joe", "Junior"}
Dim DateOfBirth As String = "UNKNOWN"
Dim DateOfDeath As String = "UNKNOWN"
Dim CauseOfDeath As String = "UNKNOWN"
In C#, the equivalent declaration would be:
var Title = "";
var GivenName = "";
var OtherName = "";
var FamilyName = "";
var NameSuffix = "";
var NickNames = new String[] {"Doc", "Joe", "Junior"};
var DateOfBirth = "UKNOWN";
var DateOfDeath = "UKNOWN";
var CauseOfDeath = "UNKNOWN";
C# programmers will have a slightly more difficult time of things (they
should be used to that by now) because var is not a keyword as Dim is in
VB.
If 'var' has been defined as a type and is in scope, then the compiler
will
be creating 9 objects of type var for the above instead of String objects
(assuming that the above would compile at all). I find in interesting to
note that this syntax causes C# to take on something of a VB look and
feel:
Dim Title = ""
var Title = "";
Dim someObject = New SomeObjectType
var someObject = new SomeObjectType();
Hmmmm...
While I find the For / Next syntax to be a little odd visually, I still
think it serves a handy purpose. As before, what is wrong with this?
For Each Dim Item In MyCollection
Console.WriteLine(Item.ToString())
Next
Variable "Item" has a scope limited to the For block and whose type is
clearly discernible. I have no use for the variable outside the For block
(and couldn't access it if I did) and all I *really* need to know is how
to
use the object when I get it. Knowing the full name of the object doesn't
affect any resulting code I write or the behavior that is generating.
Normally, I'd have to have something along these lines
For Each Item As MyCollectionItem In MyCollection
Console.WriteLine(Item.ToString())
Next
And finally as I understand it, type safety is not being violated here. In
every case, objects are being assigned a specific type and implicit casts
are still rejected. As far as I can tell, the following should be rejected
by the compiler:
Dim I = 0
Dim S = 2.0
I = S
I'm defining an Integer (I) and a Single (S). I would expect the compiler
to
object to the third line in the same manner that it does today:
Option Strict On disallows implicit conversions from 'Single' to
'Integer'.
I = S
~
The objection to this syntax is not clear to me. How does explicitly
defining the type in any of these expressions improve the code (either
from
the perspective of readability, type safety, or just plain good
programming
practices)?
There is one related feature to this that I find particularly intriguing:
the new object initializer syntax. I see this as a way to generate
dynamic,
custom purpose constructors by the consumer of a given class. I think this
has a lot of potential.
Returning to my earlier example, let's say I define the following
pseudo-class:
Public Class Person
Public Property Title As String
Public Property GivenName As String
Public Property OtherName As String
Public Property FamilyName As String
Public Property Suffix As String
Public Property NickNames() As String
Public Property DateOfBirth As String
Public Property DateOfDeath As String
Public Property CauseOfDeath As String
End Class
I'm currently limited in how many different constructors I can expose.
Perhaps:
Sub New()
Sub New(FamilyName As String)
Sub New(FamilyName As String, GivenName As String)
Etc.
What I can't do is something like this:
Sub New(FamilyName As String)
Sub New(GivenName As String)
So if I want to use this class and populate certain fields, I would need
to
do something along the following lines:
Dim P As New Person("Joseph", "Bleaux")
With P
.Title = "Doctor"
.Suffix = "Jr."
.DateOfBirth = "1/2/1950"
.DateOfDeath = "3/4/2006"
.CauseOfDeath = "Cancer"
End With
With the new syntax, I can effectively define my own custom purpose
constructor:
Dim P As New Person( _
.Title = "Dr.", _
.GivenName = "Joseph", _
.FamilyName = "Bleaux", _
.Suffix = "Jr.", _
.DateOfBirth = "1/2/1950", _
.DateOfDeath = "3/4/2006", _
.CauseOfDeath = "Cancer")
I like that.
: 2. No conflcit on XLING. I may not use it, but it doesn't hurt
anything,
: and there could be real beneifts to it.
: 3. Nullable types. I think this is a really good idea if it integrates
: with SQL Server well.
: 4. I think I will like the Query Comprehension features, because I
think
: it makes understanding certain intents clearer.
: 5. "Because extension methods are intended mostly for library designers,
: Visual Basic does not offer direct language syntax support for declaring
: them." - This kind of comment has always bugged me, and probably rubs
all
: VB developers who are serious about the language wrong. It reveals a
"red
: headed stepchild" attitude toward the language, as if C# is the "real
: thing". If you really talked to VB developers in the field, I would
: imagine what they want more than anything is just a one to one feature
set
: with C#.
Here is the C# documentation commenting about the same thing:
Note
Extension methods are less discoverable and more limited in
functionality than instance methods. For those reasons, it is
recommended that extension methods be used sparingly and only
in situations where instance methods are not feasible or
possible.
Extension members of other kinds, such as properties, events,
and operators, are being considered but are currently not
supported.
I don't see the bias against VB in this. If C# has slightly better support
for this (and that's not clear to me), it isn't substantively so.
Now it does appear that C# is getting some features missing from VB (if
I'm
reading the document correctly). One seems to be support for "Lambda
expressions" which I gather are "anonymous methods". Both VB9 and C#3 are
including support for "anonymous types" but that is evidently different
from
"anonymous methods". For whatever reason, C# will have this but VB won't
(and perhaps I'm misreading the documentation - either way, I don't see
where VB programmers are being patronized by these changes).
: But this aside, I don't really like the extension concept because it
feels
: too much like multiple inheritance and might have similar issues
: associated with it in terms of maintainability of code.
: 6. Nested functions I can see real benefits to, but it does make VB
: feel quite a bit like ML. But this could really go along way to making
: some things really easy to understand.
: 7. Relaxed Delgates. Dislike this for the same reason I don't like
: implicit type conversion.
: 8. Dynamic interfaces. Ditto.
: 9. Dynamic identifiers. More of the same.
:
: I guess my conclusion is I like some, but overall because of the
: destruction of clear typing, I have to give it a thumbs down. These
sorts
: of things should be done sparingly in clear code, so sparingly that
: programmers should have to understand the intricacies of reflection
before
: they are given a license to do them. I feel VB9 legislates bad habits
and
: practices we gave up prior to VB.NET.
:
: My gut tells me that this is really all about upgrading the tremendous
: share of VB5 and VB6 users to .NET who so far not made the transition.
I
: imagine upgrading a VB6 application to VB9 will be much simpler than any
: other .NET upgrade prior. But for those of us who have made the
: transition, I think the lack of typing is bad policy. It may simply be
: time for me to byte the bullet on curlies and semicolons
:
: --
: Justin Weinberg
: MCAD/MCSD .NET
I don't believe this has anything to do MS with trying to code down to VB
programmers nor does it strike me as being targeted at getting VB5/6
programmers to make the move to VB.net. From what I can tell, both C# and
VB
are taking on virtually the same changes with pretty much the same end
result. As I stated above, I really think these changes are framework
driven
and are not targeting any particular language.
Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
