Compartir a través de

Representing the user code by delegates ( Query Design continued ):

  • Artículo

         This post is a part of a series of posts about query design. For the previous post see: https://blogs.msdn.com/vladimirsadov/archive/2007/01/22/generic-implementation-of-iterateandapply-query-design-continued.aspx 

 

Lets’ now consider the implementation of Apply function. In theory we could somehow interpret the string inside the Apply function, but having code in a form of string still causes problems. Consider the following example:

 

        Dim number_names As New List(Of Integer)

        number_names = IterateAndApply(numbers, _

                        "squares.Add(current_number.ToString())")

 

 

Take a look at the expression. While the code seems fine, our Apply function expects that the resulting type of the expression matches the type of the collection elements. This particular expression takes Integer and returns String.

 

We can add another type argument to Apply function to represent the return type of the expression:

 

Function Apply(Of T, S)(ByVal item As T, ByVal code As String) As S

 

However this just replaces one problem with another. Someone somewhere must specify S. Generic type argument T can be inferred from the function arguments (in particular from “item”). This is not the case for S. Since “code” is just a string, there is no way of knowing the type of the results of this expression. In fact there is no way to know at compile time that the expressions returns anything or even runs.

 

Consider this example

        Dim number_names As New List(Of Integer)

        number_names = IterateAndApply(numbers, "BLAH BLAH BLAH")

This is not going to run, but compiler has no idea.

 

Clearly a string is a very bad representation of user code. Besides the problems with interpreting it provides no information on what this code returns or whether this code will work.

 

Fortunately there is a way to write a piece of code and describe its arguments and return type. For that we need to put the code in a separate function and pass a reference to that function into the IterateAndApply as a delegate:

 

   Dim numbers As New List(Of Integer)

   numbers.Add(42)

   Dim number_names As New List(Of Integer)

 

   Dim MyCodeRef As Func(Of Integer, String) = AddressOf MyCode

   number_names = IterateAndApply(numbers, MyCodeRef)

   Function MyCode(ByVal current_number As Integer) As String

        Return current_number.ToString

   End Function

   ' =====================================

   ' implementation of IterateAndApply

   '======================================

   'delegate type to represent user expressions

   ' T is the type of argument

   ' S is the type of the result

   Delegate Function Func(Of T, S)(ByVal arg As T) As S

   ' source - the collection that is being iterated

   ' code - reference to user supplied code to apply to each element

   ' returns a collection of results when user's code is applied to

   ' all lements.

   Function IterateAndApply(Of T, S)(ByVal source As IEnumerable(Of T), _

                    ByVal code As Func(Of T, S) _
) As IEnumerable(Of S)

        Dim result As New List(Of S)

        'iterate the source

        For Each item In source

            'apply the code that user has provided to each element

            result.Add(Apply(item, code))

        Next

        Return result

   End Function

   'function that applies given code to the given object and returns
'the result

   Function Apply(Of T, S)(ByVal item As T, ByVal code As Func(Of T, S)) As S

        Return code.Invoke(item)

   End Function

 

 

The code above solves a lot of problems. First of all there is no need for “magic” to apply the user code. In fact Apply function becomes so trivial, there is no need to even have it. The inner loop of IterateAd Apply could simply look like this:

 

For Each item In source

            'apply the code that user has provided to each element

            result.Add(code.Invoke(item))

      Next

 

Secondly, because user code is contained in a regular function and expressed as regular code, existing checks in the compiler can verify the syntax, type safety and everything else that can be verified at compile time.

Comments