VBA class modules & factory design (2 Viewers)

[Albert D. Kallal]

I would argue that if you are lazy (and have MZTools) then creating accessors (let, get, set) for all class variables save a lot of coding time. With MZTools it takes a second to create the accessors from a class variable, but now coding is much faster especially with larger classes. I do not have to remember variable names, scroll up to the top to see what I called a variable, or type a variable. I simply type "Me." and intellisense takes over. Further there is a good chance that the accessor needs more code then simply setting or returning the value. There may be some checks in the accessor. So I might as well start with the stub to begin with.

However, for some reason there is a shortfall in vba that defeats good use of accessors. Maybe someone knows why that is. Unlike in .Net private accessors cannot be called inside the class as would be expected
If you type "Me." they do not show in intellisense
nor can you call them by Me.somePrivateProperty
This kind of defeats the whole purpose. You have to call it without Me.

The other thing that is annoying is In VBA, you cannot have a property with a private Let and a public Get directly. VBA's property accessors (Property Get, Property Let, and Property Set) must all be declared with the same visibility level—either all Public, all Private, or all Friend.

But any var declared as public in that class? You get intel-sense anyway - hard to make a case for then writing out a getter/setter, right?

There are SOME use cases for Get/Set, but 99% of the time, if you just setting a var value? Make it public - you don't need the get/sets.....

and in regards to priviate (non public) vars in VBA class? Yes, 100% agree that me. should intel-sense those private members when writing code inside of the class.

Edit:

But, be it .net, or VBA?
Public vars do play nice with intel-sense, and that includes writing code inside, or outside of the class. And it also a nice "code smell", since then I can with ease determine which public members have code, and those that don't..........

It's a simple point here: I don't see much of any need nor advantages of building a geter/setter if you just setitng a value - make that var public, and you have intel-sense, and you have less code, and I can't really see any advantage in such cases to build that getter/setter.

Now, of course if you need other code, then of course build that getter/setter - it just "oh so often" people blind write out get/set code when no such code is required.....

R
Albert

 

[RonPaii]

I would argue that if you are lazy (and have MZTools) then creating accessors (let, get, set) for all class variables save a lot of coding time. With MZTools it takes a second to create the accessors from a class variable, but now coding is much faster especially with larger classes. I do not have to remember variable names, scroll up to the top to see what I called a variable, or type a variable. I simply type "Me." and intellisense takes over. Further there is a good chance that the accessor needs more code then simply setting or returning the value. There may be some checks in the accessor. So I might as well start with the stub to begin with.

However, for some reason there is a shortfall in vba that defeats good use of accessors. Maybe someone knows why that is. Unlike in .Net private accessors cannot be called inside the class as would be expected
If you type "Me." they do not show in intellisense
nor can you call them by Me.somePrivateProperty
This kind of defeats the whole purpose. You have to call it without Me.

The other thing that is annoying is In VBA, you cannot have a property with a private Let and a public Get directly. VBA's property accessors (Property Get, Property Let, and Property Set) must all be declared with the same visibility level—either all Public, all Private, or all Friend.

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Public Property Get LastError() As Long
    LastError = m_Error
End Property
Private Property Let LastError(ByRef NewValue As Long)
    m_Error = NewValue
End Property

 

[MajP]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Interesting. I wonder when that was fixed. That used to be a problem. Glad to see it is no longer.

 

[MajP]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time

More interesting is I asked Chat when this was fixed and Chat says it was always available. So maybe it was one of those urban myths that I assumed was true for year and never bothered checking. Which is grate because this is exactly a case where an accessor is useful.

 

[Albert D. Kallal]

Is the issue with Get and Let, only with Interface properties? I use public and private properties all the time.

Public Property Get LastError() As Long
    LastError = m_Error
End Property
Private Property Let LastError(ByRef NewValue As Long)
    m_Error = NewValue
End Property

As noted, not a huge deal anyway. But, as per above, I would have just made m_Error public - and then you don't need the Get/Let. It's a minor point on my part, and in a lot of cases, I skip the Get/Let, and just declare the var as public at the class level. As such, then the var is exposed, and intel-sense work. And I much often do the same in .net code.....

R
Albert