[RESOLVED] VS 2012 - Generic Function for Data Conversion

[circuits2]

I think I traded posts similar to this topic with john (jmcilhinney) back in 2006-2007, but I can't find them anymore.

I'm trying to get my head wrapped around Generics....again. My goal is to create a public function that resides in a module that is used to convert data in one format to another.

For example: I would call the function by passing it a string date such as "mmddyyyy" with an integer code of 2. That tells me what I am receiving and I should return the same string as "mm/dd/yy".

I could also call the same function by passing a string such as "mm/dd/yy" with an integer code of 27. That tells me I am receiving a string and should return a date object that matches that day.


So far I think I should be doing something like this:

Module Cvsn
 
    Public Function DoCvsn(Of T)(ByVal TheInput As T, ByVal CvsnCode As Integer) As T
 
    End Function
 
End Module

The problem is, I don't really understand what this code is setting me up for, or how I would proceed to code the function without losing Type safety.

Can anyone help get me on the right track?


Thanks in advance!

[jmcilhinney]

I'm not really sure that generics are of help to you here. The idea of generics is to allow you to do do the same thing with various types. It seems like all you want to do is to convert date Strings to Dates orto Strings in other date formats. That's just two methods, each with a parameter type String and one a return type String and the other a return type Date. The first thing to do is to establish what the list of valid codes is and what each one represents. I would probably suggest using an enumeration for that too.

[circuits2]

That was just the two I had for example. I have over 75 conversion codes, each of which returns either a string, date, integer, or decimal. I may not always be passed a string though, I could be passed any one of those types for conversion to another. I was hoping to create one function that can accept either type of object as well as return any type of object. Am I just thinking about this the wrong way?

[dunfiddlin]

Kinda looks that way. The whole point of generics is that it doesn't actually matter what type the input values are. A List is a List is a List. But if you're seeking to do a type conversion, it obviously does matter what the type is and, if your date example is anything to go by, not only that but also what the actual data is! You say you have 75 conversion codes but obviously not all of them will work on every input type so you will have to enclose those conversions in exponentially expanding conditionals to weed out the inadmissible and the inadvisable remembering that, in a generic, literally anything goes, all datatypes, all controls, all custom classes, forms and so on and so on! So now instead of just picking one of 75 conversions to use as the occasion demands, you'll be stuck with a conversion module of gargantuan proportion that will probably never be perfect (or even close), slows everything down while it branches through endless conditionals, and, frankly defeats the whole purpose of having a typed language in the first place. There is a reason that MS never thought of doing it that way!

[jmcilhinney]

What you're doing is not what generics are for. The idea of generics is that you specify an unknown type and then use that type in multiple places. At run time, you set a specific type and then every use of the unknown type becomes that specific type.

For instance, the best known use of generics is the List(Of T) class. It has an Add method that accepts an object of type T and it has an Item property that takes or returns an object of type T. When you create a List at run time, you fix the type T and then every use of T gets fixed to the same type. For instance, if you create a List(Of String) then the Add method will only accept a String and the Item property will only accept or return a String. If you create a List(Of Integer) then the Add method will only accept an Integer and the Item property will only accept or return an Integer.

That's a generic class. What about a generic method, which is what you're suggesting? Consider the Enumerable.ToArray(Of T) method. It allows you to take an object that implements the IEnumerable(Of T) interface and return an array of type T. For instance, if you call it on an IEnumerable(Of String) then you get a String array and if you call it on an IEnumerable(Of Integer) then you get an Integer array.

A generic method doesn't really make sense in your case. Neither does a single overloaded method. I would suggest an overloaded method for each output type. Also, using Integer codes like that is terrible. You really should be using an enumeration.

[circuits2]

Thanks John. That helps me understand why I shouldn't go the Generic route. I don't have a choice with the conversion codes being passed as integers. I receive this info from a database that is input by the user at runtime. They can dynamically select a set of fields to import based on their own custom software, and then select the type of conversion that needs to be performed on each field to make it compatible with my software. It has to be as dynamics as possible because I need it to be configurable to work with over 30 different flavors of the same type of software.

I ended up going the route you suggested and just used an overloaded method for each output type.

Thanks again!

[jmcilhinney]

I don't have a choice with the conversion codes being passed as integers. I receive this info from a database that is input by the user at runtime. They can dynamically select a set of fields to import based on their own custom software, and then select the type of conversion that needs to be performed on each field to make it compatible with my software.

Enumerations are numeric underneath, so there's no reason that storing data in a database should prevent you using one. You simply cast back and forth between the enumerated type and the numeric type.

[circuits2]

I'm not sure how I would make an enumeration with fault tolerance for something like below. Would an enumeration be faster?

This is a truncated version. I have over 25 conversions for strings of various types:

Public Function DoCvsn(ByVal TheInput As String, ByVal TheLength As Integer, ByVal CvsnCode As Integer) As String
 
        Dim TheOutput As String = ""
 
        Select Case CvsnCode
 
              Case 0
                      TheOutput = TheInput
 
              Case 41
                      TheOutput = TheInput.Substring(0, 2) + "/" + TheInput.Substring(2, 2) + "/" + TheInput.Substring(4, 4)
 
              Case Else
                      TheOutput = TheInput
 
        End Case
 
End Function