up vote 5 down vote favorite
share [fb]

I have several procedures that use the FileSystemObject. I find it's quite convenient.

Question: Is it sensible to pass an existing instance of FileSystemObject from a "main" procedure to these other procedures as an argument, rather than having each procedure create its own instance of FileSystemObject?

Example: is it better in any way to do this:

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(FSO, myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(FSO, myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub

which I have seen at least one programmer do, rather than the following, which is what I usually do: 

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(myargs)
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub

I can see the idea of doing the former in that this potentially reduces the overhead associated with having multiple instances of FileSystemObject. But it seems terribly cumbersome to have to pass FSO as an argument each time. And seriously, is the overhead really that big?

link|improve this question
88% accept rate
feedback

3 Answers

up vote 1 down vote accepted

In my opinion the overhead of creating many FSOs is not the problem; but "you should not repeat yourself" and each CreateObject( "System.FileSystemObject" ) [oops] increases the risk of a run time error. Under the hood there is exactly one file system and one file system object, so if C/C++ programmers are allowed to use STDOUT or cerr, a VBScript/VBA programmer has the right to a global FSO (you can't do anything to a singleton FSO that changes its workings in other subs/functions - except zapping the holding variable).

link|improve this answer
feedback
up vote 1 down vote

I prefer to wrap things up in a class rather than passing parameters around from sub to sub...

Set c = New MyClass
c.MainSub

Class MyClass

    Dim fso 

    Sub Class_Initialize
        Set fso = CreateObject("Scripting.FileSystemObject")
    End Sub

    Sub Class_Terminate
        Set fso = Nothing
    End Sub

    Public Sub MainSub()    
        OtherSub myargs
        ' call other subs and functions that use fso
        ' or use fso here
    End Sub

    Public Sub OtherSub myargs
        ' Do stuff with fso here or call another sub in the class
    End Sub 
End Class

.

link|improve this answer
1  
Fake OOP. I like this. – Jean-François Corbett Jun 29 '11 at 13:04
feedback
up vote 2 down vote

I have done something like this recently, and I personally prefer to use a single file system object wherever possible. I think of it as passing file handles between functions, which in-turn write to the open file handle.

When defining your functions/subs, be sure to pass the file system object using the ByRef keyword.

The only time this would be unacceptable is if you are navigating through a file hierarchy, and you need the FSO to maintain the same directory. It should be noted, however, that the memory requirements of a single FSO are negligible in today's computers, and you will only notice a performance gain if you need to use a recursive function or repeatedly call a function which creates/destroys these objects.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.