@ Head

An Interface is a simple contract. When you mark a type as implementing an Interface you agree to provide the methods and events that Interface defines.  A key to that contract is those members are always accessible via the a cast to the Interface, even if they are not accessible in the implementing class.

Fro example, let’s say you have an Interface:

Interface IFoo
    Sub Bar()
End Interface

A type could implement that such as :

Class MyType : Implements IFoo

     Private Sub Bar() Implements IFoo.Bar
       ….
     End Sub
End Class

Now note, that even though the interface implementation is marked as private, code from outside the class can still call into that method via the Interface mapping.  Without the Interface mapping they could not. 

So far we have just looked at the basics, common to both C# and Vb.NET, but C# does not use declarative mapping like VB.NET does.  The declarative mapping, helps formalize the interface contract in a flexible and robust manner.

Flexibility is gained from being able to map by signature, not reliant on name.  So code the above implementation could also have been written as :

    Public Sub DoIt() Implements IFoo.Bar

And as the signatures match that is a valid interface mapping, the contract is preserved.

Now when you consider your code in it’s environs, not in isolation, you need to also consider the “what-if’s”, the possibility of change.  At one side you have the Interface (which ideally you would hope won’t change, but it might) and on the other side the requirements of the calling code, which might be using your public methods or might be accessing via the Interface.  So the robustness of your code depends on how well it can implement change as required by surrounding requirements.

So let’s consider a simple change, the calling code requirement becomes that the method should be named DoThat instead of DoIt.  In Vb.NET, not a huge problem, you just modify the DoIt to DoThat.  Obviously all calling code will need to be modified too, but the change was required by the calling code.  The change inside your class can be atomic. (it might not be atomic if you call the method elsewhere in your class, as then your class’s code also becomes the calling code)

Now let’s consider the interface changing.  Say Bar became Stick.  To make that change in your class, you simple update the Implements declaration to Implements IFoo.Stick.   The change is atomic.

Okay so let’s look at how C# deals with this, and hopefully you will start to see the benefits of declarative interface mapping.

In C# you have two approaches you can take.  One is to use implicit mapping, the other is to use explicit mapping. 

Implicit mapping is fraught with potential to break.  It works on matching signature and name. Taking for example. The IFoo.Bar changing to IFoo.Stick.  If you had both void Bar(){…} and void Stick(){…} in your class then suddenly, the code would be pointing to a different method than intended.  The contract has shifted.

So rather than have code subject to naming change issues or naming conflicts, a common approach is to use explicit implementation.  With explicit implementation, the method would become:  void IFoo.Bar() { … }  The problem then becomes that you cannot access that implementation even from inside your class without first casting to the interface.  Code inside the IFoo.Bar method can however call into your class’s code, so the common approach taken is to delegate out to an accessible method rather than have the accessible method call into the interface implementation.  So you might have:
void IFoo.Bar() {Bar()}
public void Bar() { … }

This pattern allows name changes in the Interface to be atomic, but name changes in your own class now cannot be as the coupling requires delegation via the method name.

Now at this point some of you are probably saying “yeh sure, but what about when the signature needs to be changed”.  Well if you look at it, I think you’ll find that the VB code can be more atomic in every case, whereas the C# code faces a different set of issues depending on whether implicit or explicit interfaces were used.

Apart from the elegance and robustness that declarative interface mapping provides, it also provides greater functionality such as allowing multiple methods to be mapped to the one method, and it provides a clear indication of the interface and the mapping.  That is, when you read the code, the interface definition is clear form the implementation.
Compared to C#, where implicit interfaces are not clear. You need to first ensure you know the interface exact signatures  and scan the entire code to ensure that explicit mapping isn’t used. Only then can you jump to the interface implementation.  Or explicit mapping where you often have to look at the explicit interface implementation and then read what method it delegates out to (not absolutely necessary, but is the usual pattern). This later pattern means it may not be obvious when editing a particular method that is being called indirectly for the interface implementation.

To sum up, the CLR provides for true interface mapping.  VB.NET provides this via clear explicit declarative mapping, in a robust and flexible manner.
C# also uses the same CLR provided mapping, but does not actually implement that to the developer in it’s fullness, rather the developer is forced to choose between explicit interfaces (which often means extra stubs in your code calling out to the actual implementation, and is only callable via a cast to the interface even from within your own class) or implicit interfaces which are fraught with dangers and lack any indication of the actual contract.

The benefits of declarative mapping are that code becomes easier to maintain, is more explicit in nature hence easier to read, and is more flexible and robust.  Without doubt, the VB.NET implementation is more elegant than the C#, and more suited to the future as we move more and more into the world of declarative programming. 

Congratulations to the VB.ENT architects on this one.  Job well done ! Although admittedly they just implemented the CLR capabilities in its fullness, whereas C# didn’t, or did so in a very ugly way 

Via, Yag, Paul, and Jay, Scott touched on some of the nice things VB.NET has to offer.  So I thought I’d add to that list the things I love. Some of these are what I see as improvements over VB6, some as advancements compared to C#....

- Block property declarations.   This feature is one I use the most often (how can one avoid it after all <g>), but it is also one I really love.  It just feels more anatomically correct ;)

- Structured Error Handling. (SEH) .  Once again, this just feels more natural to be able to explicitly wrap a block of code inside a specialized error handling block.  OF course you can achieve the same pretty much with VB6 style On Error GoTo, but the clear explicit structure is not there, rather you have to interpret it from the spaghetti

- Pretty listing.  Yeh it’s just an IDE thing, but one I love.  No more worrying about indenting code manually.

- Option Strict.  Detect errors at design time, rather than runtime.

- Background compiler.  Detect errors at design time rather than compile time.

- Formal Interfaces declarations.  Sure you could do these in VB6, but it felt more like an abstract base class rather than an interface.  So it’s more a style than a functionality thing, but one I like :)

- Explicit Interface mapping.  This is incredibly cool.  Unfortunately a lot of people just don’t get how important this concept is to true OO.  I’ll blog about this separately me thinks, suffice it to say for now is that it formalizes the contract in a clear robust explicit and flexible manner.

- Delegates.  Them just sweet.  Not syntax sugar kind of sweet, no, these are the purest finest honey :)

- Parameterized constructors (as Scott mentioned).  This really comes in handy when creating object purely to pass to another method.  When all is said and done it really is just a matter of cutting down on lines of code.

- Multiple types per code file and Nested Types.  Multiple types per code file is great when wanting to write quick tests etc, but I do tend to split code out to one type per code file for the most part. Nested types on the other hand are really cool as they allow encapsulation of types you don’t want exposed.

- Explicit Event handler mapping

- Explicit structure member layout. With win32 API this rocks !

- Explicit casting.  CType or DirectCast, such as CType(myfoo, IBar).DoIt

- Implementation Inheritance.  I think this one is highly over-rated, but it is also indispensable when you do really need it.

- Threading.  Also often over rated IMO, but also indispensable when you need it.

- ASP.NET versus ASP. No comparison, asp is just scripting totally devoid of event driven structure or strong typing etc.  ASP.NET kicks azz !!

There’s probably a lot more little things but I’ll leave the list at that for now. As to VB.NET over C#, VB.NET is actually a far more OO language when you look at the actual implementation details. It also is case insensitive which is closer to natural language. (u don’t have 2 spe4k 1337 to gr0k that 1) , and it is written more like we speak. The most obvious example of which is the End xxx constructs.  Compare VB.NET code to the }}}} of closing a if block inside a method inside a class inside a namespace, and you should easily see what I mean .

As to VB6 compared to VB.NET,  I think many of the enhancements I list above could easily be applied to VB6.  Yes I do strongly believe that another version of VB6 is still warranted, one with many of these enhancements.

The IsNot patent issue is raising its ugly head again.  And although I agree with Cameron that Paul and Amanda are some of the nicest folks (I don’t think I’ve met Corneliu), I still think this is an issue that they need to fix !

Over the last four or five years’I’ve had a fair bit of interaction with both Paul and Amanda.  And a fair bit of that has to some extent been differences in opinions (especially with Paul <g> ).   But even when I have thought them somewhat clueless on a particular aspect of a discussion I’ve never really taken that as a personal short coming, rather just the need for more persuasive discussions .  That is, even though we have disagreed, I’ve always felt there was a level of sincerity there. And I think that even if you disagree with someone (even strongly at times) discussing those issues and interacting with them over a period of five or so years, well yo’ can’t help but have some respect for them. 

But the IsNot issue is different from any differences in opinions, this really cuts down to the level of credibility and an issue of personal substance.

Technically I think Paul has even alluded to the lack of merit of the IsNot patent.
And of course there is the issue of how VB.NET is proprietary whereas C# is made open license.

The real issue though is that there was and is clear prior instructions given on it.  A simple search for IsNot in the Visual Basic forums, shows references to it many years before this patent was applied for.  Now whether Paul and Amanda dreamt up the IsNot concept themselves, or whether they had heard it and forgot that and it somehow muddled in their subconscious, or perhaps they weren’t listening, we’ll never really know, and perhaps they themselves will never really know, as with so much information processing by humans things can sometimes get muddled. Regardless of whether they think they invented it or not, they failed the basic rule of research. 

The issue now, as it stands, is they have since been made aware it was in the public domain long before.  The simple instruction saying have an IsNot operator that is the equivalent of “Not Foo Is bar” is sufficient instruction for anyone skilled in the language and the compiler to implement it. That’s a simple fact.

So really, I think Paul and/or Amanda should do the right thing and write to the patent office and tell them it has come to their attention that there was in fact prior art, and hence they no longer believe the patent is valid.  In doing so, they still gain protection from anyone else applying for said patent as the prior art in the public domain has already been established. 

And of course this would also allow other versions of Basic such as Mono’s VB.NET to include the IsNot operator.

Anyway, as much as I agree with Cameron about Paul and Amanda, this patent issue has actually discredited them in my eyes.  I view it as plagiarism, and even if it was not intentional, it is still up to them to fix that. As long as they don’t fix it, it can only be viewed as intentional plagiarism.

And that then leads us to the question of whether or not the community can make suggestions, freely giving concepts and ideas for the betterment of the community then have employees of Microsoft file for patents on the implementation of those concepts.

I really think it is about time Paul and Amanda stepped up to the plate andwithdraw this reidculous patent.

Jay Roxe blogged about RegFree COM.  What this basically is, is when you use .NET to interop with COM on Windows XP or higher, you can use side by side COM.  Side by Side COM (SxS COM) has actually been with us for years now, but it too didn't get much publicity back early on this decade as at the time .NET was the push for the end of dll hell. 

Anyway *if* you are working with windows XP or later (not NT, 2000, ME, 98, or 95), then you can take advantage of SxS COM from both your unmanaged applications as well as your managed ones, or will be able to with Vs.NET 2005.

There's a lot of talk about Microsoft's AnitSpyware program in the press lately.   Seems new virus writers now are trying to remove it from systems, much like how they target firewalls and anti-virus programs.   One can only assume it's got virus writers scared

But one thing a lot of people probably don't realize is that Microsoft's brand new Antispyware program (currently in Beta 1) is actually written in Visual Basic 6 (service pack 5).  And it's a great program. Small footprint, great UI. Download it today

In Whidbey both Vb.NET and C#  get strongly typed resources.   But the intellisense story is very different

When hovering over a resource named AResourceString in C#, intellisense display the type information and the comments, hence displaying the default value for the resource..

In Vb.NET, this is all you get, just the type:

So as you can see, editing the C# code is much more friendlier. You can tell instantly that AResourceString defaults to "this shows in C# but not VB".

There's been a bit of talk about CAPTCHA lately, and stemming from that I think I have a better solution to the problem...

 f'ing SPAMMERS are causing many blog to implement visual CAPTCHA's... those damn pesky things that make you squint and try to decipher the letters and type them into the textbox.  Visual CAPTCHAs have a number of problems:

(a) computers can actually crack them relatively easily

(b) humans have difficulty with them

(c) inaccessible to the visual impaired (or hearing impaired if it's an audio CAPTCHA)

(d) spammers can still just cut and paste their spam to your site and submit in probably less than 10 seconds easily. 

 Considering spammers are a'hole yokels with nothing better to do with their time, we need to prevent them manually posting (d).  

So what's a better approach ?  What's the answer ??  CONVERSATION

That's right, do what humans do rather than have computers trying to generate things to prove you aren't a computer

Let's say we add an extra field to a post, a simple text field (probably < 255 char). I'll call that field the "key".  Then when you post a blog entry, you also fill in the key.  And for anyone to post a comment they have to put that key in the title. The server would read the title, if the key is in there it accepts the comment and removes the key from the title, otherwise it just rejects the comment.  The real trick here is how do you let the readers of your blog find the key ?  Easy, you include it in the conversation, either directly or implicitly.

For example, say I set the key to "dog".  In my blog entry I might write "To reply include what has four legs and barks"  or "To post a comment " what is man's best friend".   So even though the key is static, as is the clue, it's a one off and hence incredibly difficult for a machine to guess, especially as they don't know where in my blog post the clue to the key will be posted.  And it stops those cut and paste spammers as they too have to stop and read the actual entire blog entry.  Plus it's accessible to the visually impaired.

So really, all along I think the answer to blog spam has been looking us in the face... use CONVERSATION, not CAPTCHA