Re: Some thoughts on VB9
- From: "CMM" <cmm@xxxxxxxxxx>
- Date: Sun, 26 Feb 2006 14:43:58 -0500
A Document Outline for code that displays #regions as well as groups members
by type (Methods, Properties, etc). I saw at the Feature Request Labs that
this is
already in the pipeline but I'm not sure how many people have voted on it.
Done right, this would be awesome.
Smarter Code insertion. I don't use #Regions very much (I find them to be
unwieldy given the lack of a Document Outline mentioned above) BUT I do like
to keep
related types of methods near each other in the file... like all my Property
Accessors at the top and all my Event Handlers towards the end of the file.
When I double click on a Control I'd like the code to be inserted near other
event handlers.... not in the (seemingly) random way it's inserted now.
Visual Attributes Editor. Attributes (or at least a common set of them)
should show up in the Properties Toolbox (or something similar... like the
way Code Snippets appear) when the cursor is positioned on the
Method/Function/Property name line. I can never remember the exact syntax of
the oodles of attributes that I often want to apply to a property.
Refactoring in VB2005 is pretty lame. I like the right-click "Rename" symbol
feature but that's pretty much the extent of refactoring in VB2005. The 3rd
party free Refactor! Lite tool MS touts as a workaround is OK... but I'd
like to see this as part of VB proper.
Super-Smart Find. Regular Expressions is cool... but Find is still pretty
dumb. I'd like to be able to search by Type- (Find Next
"System.Windows.Forms.Control" reference).
Probably no other thing will the give the VB community a slap in the *ss as
a good set of Coding Standards Recommendations from MS. No, public Object
Model recommendations is not enough. This would go a long way to helping VB
achieve the same level of respect given to other development languages. It
is for good reason that VB developers have a bad rep.... because we tend to
write bad code because we feel like it and because we can. Open up two
different applications from two different VB developers and you will see
WILDLY different code standards.... this makes maintaining VB programs a
NIGHTMARE.... and it is for sure a BIG reason corporations are trying to
move away from VB and to C#.
--
-C. Moya
www.cmoya.com
"Justin Weinberg" <jweinberg@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uklfXglOGHA.1312@xxxxxxxxxxxxxxxxxxxxxxx
My thoughts on this....
http://msdn.microsoft.com/vbasic/Future/default.aspx?pull=/library/en-us/dnvs05/html/vb9overview.asp
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.
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#. 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
.
- Follow-Ups:
- Re: Some thoughts on VB9
- From: CMM
- Re: Some thoughts on VB9
- References:
- Some thoughts on VB9
- From: Justin Weinberg
- Some thoughts on VB9
- Prev by Date: Re: How to invoke IE ...
- Next by Date: Re: at run time database connection
- Previous by thread: Re: Some thoughts on VB9
- Next by thread: Re: Some thoughts on VB9
- Index(es):
Relevant Pages
|
