"Namespace" reserved in VBA?

[Pat Hartman]

Not that you should, of course, but the reason I generally would is efficiency, unless I had a specific reason to use ByVal.

Most people would consider ByVal to be safer since it exposes a copy of a variable rather than giving the calling object the address of the variable in memory which allows the called procedure to change the value in the calling procedure. So they would use ByRef ONLY when they actually wanted the called procedure to update the variable's value.

 

[Pat Hartman]

I can't imagine many reasons at all to keep any configuration data in a FE.

I keep things like the menu list in the FE. That means that when I add a new item to a menu or rearrange the order, the changes go with the FE. If I were to put this table in the BE, then I would need to have to coordinate updating the table in the production BE and force all users to update their FEs at the same time. Usually that isn't necessary when I am making small changes. So I just send out an email with a note of the update and if the user needs it, he shuts down the app and reopens it. Otherwise, he gets the update silently the next time he opens the app.

 

[riktek]

Most people would consider ByVal to be safer since it exposes a copy of a variable rather than giving the calling object the address of the variable in memory which allows the called procedure to change the value in the calling procedure. So they would use ByRef ONLY when they actually wanted the called procedure to update the variable's value.

Well, that's exactly the tradeoff. That insurance carries a premium and the relative values can only be evaluated subjectively. Going in the deep end isn't as much of a problem if you can swim, as it were.

 

[Pat Hartman]

Going in the deep end isn't as much of a problem if you can swim, as it were.

It's like a safety play in bridge or a defensive driving technique. You don't know who will be modifying the application when you leave your post. You don't know their skill level, so you prevent one kind of accident from happening. Some things don't have to be so efficient that you would give up safety in exchange. If you're talking about a code loop that processes millions of entries, maybe you need to consider efficiency.

 

[riktek]

If you're talking about a code loop that processes millions of entries, maybe you need to consider efficiency.

There's that, of course, but it also matters in object frameworks, garbage collection, filtering routines, and rendering GUI elements, especially things like complex TreeView controls.

Nevertheless, it remains a subjective evaluation.

 

[Josef P.]

For objects, ByRef passes the pointer itself, while ByVal passes a copy of the pointer (not, to be clear, another instance of the object).

A copy of the pointer => This is for me irrelevant in terms of time.
However, I use the interface to show that the object reference will not be changed.
For me, this is worth more than the time that may be needed to create a copy of the reference.

Tried it out briefly:

Private Function ProcByVal(ByVal AppRef As Application)
   ProcByVal = AppRef.Name
End Function
' VS.
Private Function ProcByRef(ByRef AppRef As Application)
   ProcByRef = AppRef.Name
End Function

With 1 million function calls, the difference was 20 milliseconds on my PC. This is negligible for my applications.

The incorrect use of ByRef

Private Function WrongProcByRef(ByRef AppRef As Application)
   ProcByRef = AppRef.Name
   Set AppRef = Nothing  ' <---- But that never happens, does it? ;-)
End Function

For array parameters, VBA forces the use of ByRef.

ByRef vs ByVal (for value types)
I also use ByRef if I want to return something. This clearly defines for me in the interface what can happen with the parameters.

Typical example: Return Value with ByRef parameter in Try* functions

Private Function TryConvertDate(ByVal ValueToConvert As Variant, ByRef ConvertedDate As Date) As Boolean
    ...
End Function

' use:
dim ValueToConvert as Variant
dim DateValue as Date
...
if Not TryConvertToDate(ValueToConvert, DateValue) then
    Err.Raise ....  or set something and/or exit procedure or ...
end if

However, ByRef can also be useful to prevent implicit conversion.

Private Sub Test()
   Dim X As Variant
   X = "2.5" ' test with 2.5 or 2,5 ... If the dot is the decimal separator in the regional setting, please use "2,5"
   Debug.Print X, DoubleParamRequiredProc(X)
End Sub

Private Function DoubleParamRequiredProc(ByVal DoubleParam As Double) As Double
   DoubleParamRequiredProc = DoubleParam / 10
End Function

vs.

Private Sub Test()
   Dim X As Double 'use: As Variant => compiler error
   X = "2.5" ' test with 2.5 or 2,5 ... If the dot is the decimal separator in the regional setting, please use ,
   Debug.Print X, DoubleParamRequiredProc(X)
End Sub
Private Function DoubleParamRequiredProc(ByRef DoubleParam As Double) As Double
   DoubleParamRequiredProc = DoubleParam / 10
End Function

To summarize, I use ByRef when it is useful for the code, otherwise I use ByVal.
But this is just my personal approach, if you only use ByRef and always make sure that parameter values are never changed, then of course this is correct.
Perhaps this is also due to the fact that I also program a lot with C#. There, ref or out is rarely used.

BTW: [Classes and VBA]

But, YMMV. I'll be the first to admit this view largely can be attributed to a nitpicky style, or too much time spent programming classes.

Honestly, I never understood why classes are often considered complicated. For me, they're just a regular part of working with VBA.

 

[riktek]

The incorrect use of ByRef

Just the thing to avoid.

Of course, I've never encountered any such thing in my code. ;-)

But this is just my personal approach, if you only use ByRef and always make sure that parameter values are never changed, then of course this is correct.

Very interesting examples.

That's the thing: It's perfectly valid or correct to have a style preference for one or the other, but only if one pays deliberate attention to the consequences. If one does, no worries, but one must.

ByRef clearly carries more risk. As much as I might prefer it as a default, I wouldn't if I weren't in the habit of being deliberate and express with each declaration, and deliberately aware of how a procedure acts with or upon each reference.

Perhaps this is also due to the fact that I also program a lot with C#.

I expect that explains a great deal. I don't work with C# but fiddle with VB.NET and Win32 enough to understand that the prospects of passing an argument out of process are such as to require ByVal not just as default but practically as a matter of course. Access isn't even threaded, so it's a different ball game.

For me, this is worth more than the time that may be needed to create a copy of the reference.

Overall, a very interesting and thoughtful post, and thanks. I'll be giving it a few more close reads.

Honestly, I never understood why classes are often considered complicated. For me, they're just a regular part of working with VBA.

From experience, I can say that the notion of instantiation is a significant conceptual leap for those without formal CS training. They don't know what they don't know. The bigger problem, however, is that those who do understand the topic quite often don't, either, and so are incapable of explaining it.

I've had this discussion with other senior Access developers, but moving, e.g., from Excel to Access without such training requires crossing not one, but two conceptual chasms, apart from gaining some proficiency with VBA and SQL. Once I explain, those developers' reactions consistently has been recognition and astonishment that they hadn't grasped how little of their foundational knowledge was commonly held.

The first, and easier of the two chasms to cross, is what I call the "back-end" chasm, normalization. Chiefly because their experience is limited to two-, or perhaps three-, dimensional representations in worksheets and workbooks, many have difficulty conceptualizing normalization and table relationships. Many never get it, and struggle even with the native lookup functions.

To your point, the second and more difficult conceptual chasm to cross, what I call the "front-end" chasm, is instantiation. E.g., it will come as a complete surprise to someone accustomed to data residing on/in a spreadsheet, to learn that they can use the same subform on three different main forms simultaneously. Then, advancing from programming forms and controls with anything more than macros and filling out property sheets, to meaningful VBA, is another step. Going further, VBA lets one gloss over or even ignore many of the basics of declarations, pointers, and scope when simply programming forms and controls. Programming classes is impossible, however, without a far deeper and more fundamental grasp of these concepts, their interaction, and event progression because the task then includes memory management. Over time and with practice, one can keep more of these balls in the air but recognize that neither the topic nor many of its constituent elements are necessarily even apparent to virtually anyone, and when they are, not fully understood.

To give you an idea, I have two postgraduate degrees, one of which fairly quantitative but neither of which involved CS or required any programming, from places most people have heard of. In school and at work, I became a power user in 123, WordPerfect, Approach, Excel, etc. and yet never encountered even the concept of a development environment. Write code? Great! Where? Then, what? Literally. Bad enough that I had to, but far worse that anyone might think I would, could, or even had the first idea where to start. Then, IBM orphaned Lotus Approach and I was compelled to embrace Access. I got started and now, years later, am informally editing others' book drafts on the topic by invitation, giving an occasional developer presentation, and realize the VBE is a shell.

Get to a certain level and it's easy. Just like playing Chopin, or Brubeck.

 

[Isaac]

"Namespace" is reserved in VB.NET but is not documented as such in VBA, as far as I can tell.

VBA bucks a bit when I attempt a "Public Property Get Namespace()" but seems to take the bit after compiling, saving, and cycling the app a few times.

Lest I court disaster and before I go too far down the road with this, however, I thought I'd check here for thoughts about such usage. Thanks in advance.

Even if it isn't technically reserved, why come so close?
Readability/avoid confusion

 

[riktek]

Even if it isn't technically reserved, why come so close?
Readability/avoid confusion

You answer your own question, actually: Readability. It's a well-understood term and the concept is directly relevant to the project.

It is close, which is why I posed the question in the first place. The consensus seems to be that close is perfectly safe and acceptable because there are no grey areas in compiling; the result is binary. Something will compile, or not. Put otherwise, the compiler can't distinguish "close" even if we think we can.

 

[Isaac]

I guess you make a good point. For readability, the closeness to being reserved could be its strength, depending on the context and who is reading it, though I'd still probably choose something like MyNamespace or something, but I do see what you mean.

Doc will say I am a belt & suspenders type of guy, and maybe I am, but I can also code SQL where ambiguous or nearly-ambiguous things exist, like the alias of the outer apply is called PatientInfo, and the column it returns is called PatientInfo, and the column alias in the Select block is PatientInfo, so that it reads:

PatientInfo = PatientInfo.PatientInfo

...But I don't, as I feel someday the clouds may gather somewhere deep in the universe of the software's black box and come back to bite me....

 

[riktek]

Close is one thing. Looking for trouble is a whole other kettle of fish.