Signature Follies

Every once in a while I learn something that seems so basic, so foundational that it makes me cry that I didn't learn it sooner. The heartache... the endless hours of coding around a perceived problem. It just sickens me. Today, one of these "revelations" was brought to me by a <ick> VB programmer (Check).

How would you like to have a method (sub/function for you VB'ers) dynamically overloaded with an infinite number of signatures? Well, there is a way... and I'm told this capability has been available in VB since 6... and perhaps C as far back as Kernigan and Ritchie (what do I know). [I think I'm going to hurl now.]

When I first taught myself to program... it was a variant of BASIC for the Commodore 64. The book that guided me was written for IBM-BASIC. It was a stretch, but by no means too difficult of a syntactical difference to cause any issues. It was all procedural, and lent itself to extremely longwinded coding. I moved on to dBase in the early 90's; that was still procedural. I toyed around with HTML2-3.2 for a few years (also procedural), but it wasn't until I learned C in college that I discovered Classes... and the holy grail of programming, OOP (aka Object Oriented Programming). I didn't actually get to build classes IRL until I learned that ASP2 (VBScript) supported classes on 9/11. Working in DC, everyone was flipping out.. and all I could think was.... Eureka! Classes in ASP!

Designing classes was my new favorite hobby. I wanted to program so badly in those days... and I learned quite a bit about OOP. For instance, each method has a signature that when compiled uniquely identifies it during runtime. Each signature is made up of the methods name, any return variables (and their type), and a slew of parameters. If you set 3 parameters... then you had to use those parameters EVERY time you called the method. No more, no less. Simple enough.

If for some reason you wanted to overload a method, you would simply declare the method numerous times with the same name but with different parameters (using the appropriate syntax for your language). If you wanted to use the same code in each method with only slight variations you could extract the code into a separate private function - and, Voila! You would then call your method with any of the sets of parameters of each of the different method signatures. Ahh... flexibility is good.

But what if you don't know how many parameters you will have? Perhaps you don't know prior to run time... or you want to make this method generic enough to use in the future with any number of parameters that you had the need to pass. Enter the Array.

The array is a sweet piece of genious that allows you to, in effect, pass a table (hierarchical) of values.. with any number of rows (or dimensions). Depending on the language you could pass a strongly typed array of values or a (dimly lit) generic one. Sweet. I thought I knew it all... posh!

Then along comes a VB programmer who told me that if you stick the array at the end of a method's declaration of parameters... the compiler would dynamically generate any number of additional signatures automatically! OMG! Awesome!

Ok, what does all this mean? It means that when declared like this (thanks to Check for the copious links):
C#: public void MyMethod(int iVar1, string sVar2, params object[] list)
VB: Sub MyMethod(ByVal iVar1 As Int, ByVal sVar2 as String, ByVal ParamArray list() As String)

    // you can do any of the following:
  • .MyMethod(iVar1, sVar2)
  • .MyMethod(iVar1, sVar2, var3)
  • .MyMethod(iVar1, sVar2, var3, var4, var5, var6, var7)

And the bonus is -- if the variables passed are strongly typed (as in C#) the datatype is inferred. Wow, I'm speechless. This kind of thing should have been in my college classes... and taught as a basic capability! I'm talking CS101 here. I feel appropriately stupid now. I'm going to crawl back into my hole. Good night.

«December»
SunMonTueWedThuFriSat
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678