Chapter 5

Functional Programming’s Last Gasp


One of the first readers of the first edition of Hardcore Visual Basic sent me a program he was working on. When I opened the project, something very strange jumped out at me. No standard modules. Just forms and classes.


Wait a minute! You can’t do that with Visual Basic. But hardcore programmer Peter Wheat did, and the program worked just fine.


The object-oriented only approach is a lot easier with version 5. Many of the object-oriented holes in Visual Basic have been plugged.


Still, we’re not quite ready to give up on functional programming. Visual Basic doesn’t. Imagine if it did. You’d have methods and properties on the String type:

Dim s As String, c As Long, i As Long
s.Text = “Stuff” ‘ Or use Text default: s = “Stuff”
c = s.Len ‘ Not c = Len(s)
i = s.In(“f”) ‘ Not i = InStr(s, “f”)
Print s.Mid(2, 4) ‘ Not Print Mid$(s, 2, 4)

Why not? That’s how most object-oriented languages handle strings. Theoretically, you shouldn’t have anything left in the globals section of the VBA library. But how far are you willing to go? Take a look at the following examples before you decide:

Dim r As Double, i As Long
r.Value = 5.2 ‘ Or use Value default: r = 5.2
r.Plus(1) ‘ Not r = r + 1
i = r.CInt ‘ Not i = CInt(r)
Me.Print r.Cos ‘ Not Print Cos(r)

Some of these examples might be getting a little marginal. Even completely object-oriented languages support operators and passing objects as parameters. I think there’s still a place for a tight library of procedures that aren’t methods of anything.


This chapter will explain an efficient way to create such a library. Then it will discuss some of the general purpose tools you might still want to put in such a library. Even though the focus of this chapter is functional, we won’t escape ob­jects. COM depends on object-oriented programming, and Visual Basic depends on COM, and we depend on Visual Basic, so objects will keep popping up.