[AccessD] Class Rebuttal was: Basic Unbound Form ...

I'll get back to the Public variables in a second.  I want to discuss this
property get/let that you are hung up on.  You specifically gave an example
of a value out of range for an integer.

Now, there are two ways to approach this.  Let's say you have an integer
field, and you want your class to be able to deal with values that may be
out of range for that field.  Then you would obviously use a get/let
statement, and deal with a larger number in whatever way you choose.
However, that field would have to be a long integer if it was possible to
receive values larger then an integer.  Leaving it as an integer can only
check for values in the integer range.  (I'll get to that in a second).
However, I never said that you should declare a public variable in a class
in all situations. If you need to do work on a value, then you use get/let.
This still does not invalidate the use of Public in a class module.

If the property of the class is an integer, it doesn't matter if it's
declared as Public or get/let, sending it a value outside of the integer
range is going to react EXACTLY the same.  The code calling the property
will get an overflow error.
So that argument is out the window, and my comments about error handling in
a simple (get/let a value) property still holds.

You've brought up that it helps you know what's calling your code.  No, it
doesn't.  You can stop the code there, but you have to follow it through to
do that.  If you need to do that, it takes all of 21 seconds to turn a
Public into a Get/Let for debugging.  The 'that variable can be used from
anywhere' is a VERY crappy argument.  If you don't know where you are using
things in your code, then using Public variables (in a class or basic
module) is the least of your worries!

Any more arguments about using Public in a class module for a simple value
storage property???  Haven't heard one compelling reason yet.  And you have
shown no reason why their use would be 'buggy', or bad in anyway.  The only
thing your arguments have shown is your preference, which is just fine and
dandy.  I am NOT arguing that you should use one method or the other.  I am
arguing that their use is not 'bad practice', because the 'issues' you have
brought up are personal prejudices, not faulty designs.

Onto Public variables.  Why in the world would Public variables be left in
VB/VBA as backward compatibility???  Other then older versions of VB, you
can't cut and paste other languages into VB without some modification.  You
say there isn't a reason, well, then you just haven't had projects that
require them then.  Again, that doesn't make public variables 'bad
practice', it just means you have had limited experiences where they are
required.

As you know, there are three levels of variable scope in VB/VBA.  Procedural
Level, Module Level, and Global.  A public statement in a class module is
NOT a Global variable.  It is a module level variable.  It's value is only
contained within the class module itself.  Why do we have three levels of
scope?  Because ALL THREE levels serve a unique purpose.  

The Global scope has a purpose.  It's purpose is to provide accessibility to
anything in your project.  So let's say I have a class with an event that
many other objects need to 'see'.  Sure, I could put that class into a form,
and reference that form from everywhere, but hey......wait, that would be a
Global form.  It also is no more or less 'buggy' then creating a global
instance of that class.  If the code execution is stopped, that form's
object loses it's values too.

Drew

-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at aig.com]
Sent: Monday, June 12, 2006 4:16 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...


Hello Drew (and anyone else following along in the discussion - feel free to
chime in),

'Next, "but globals are bad news in any context", not this again.  Public
variables are not BUGGY, nor are they 'bad news'.  They have a purpose, that
is why they are there in the first place' .

Sorry , can't agree with that either. Public variables are there so that
code written for ancient systems, running languages that had only one kind
of variable - public ones - can continue to be run. It's a backward
compatibility feature. I know that may seem like a bold, overarching
statement, but look at the history of programming languages. Why was the
concept of 'local variables' dreamt up? Because having all global variables
was a nightmare The fact that lots people (myself included!) have a tendency
to cut corners and use them as a quick and dirty way to get data moving from
one module to another does not mean that it's a good idea.  There's really
no excuse for using a global, as rewriting the code to use local variables
requires very little effort.

Likewise, writing a few lines of code to implement a very simple Let/Get
pair of properties is not difficult. But the benefits are that you know
exactly how and where your class' data is being changed. If you pepper your
classes with public members fields then you have simply throws away 50% of
the reasons for using classes. If you think that code is better because it
uses less lines, or characters or pixels on screen, dots on paper or
electrons moving though wires, then you are simply mistaken. I'd rather
spend my time writing the few extra lines of code that the extra time needed
to debug it when it behaves oddly. My argument against the use of globals is
not based on the peculiarities of VB ("they lose their values" [if a runtime
error is not trapped]) it's based on the idea that a global, by its very
nature can be modified from almost anywhere at all in code, and that  makes
for a debug/maintenance problem.

So if I were teaching someone some VERY basic code, like how to calculate
the cube of an integer I COULD write this...

Dim nNumber as Long

Sub TryItOut
     nNumber = 7
     Debug.Print "The cube of " & nNumber & " is " & nNumber^3 
End Sub

.. Which illustrates how variables are assigned values, how to use the
'power' operator and the concept of outputting results for debugging.

However I would probably write...

Function nCube(nNumber as Long) as Long
	nCube = nNumber^3
End Function

Sub TryItOut
Dim nLocalNumber as Long
     nLocalNumber = 7
     Debug.Print "The cube of " & nLocalNumber & " is " & nCube(nLocalNumber
) 
End Sub

Both examples do the job, but the latter version, at the cost of writing
some more code, illustrates the concepts of local variables, parameter
passing, functions calling and function return values. All essential to
ordinary day-to-day programming. 

Regarding your error class example. "Both routines cause the same error, and
stop at the same point.  The SecondValue error NEVER reaches the
ErrorHandler!!!  If a property of a class is going to do NOTHING but hold a
value, the only error you can get involving the use of that value is going
to fall into the domain of the calling code.  If you are setting an invalid
value, i.e., wrong type, too big, etc, the error is going to occur in the
code trying to set the value.  Quite frankly, putting error handling in a
property get/let combo above is pointless, it will never be used (unless it
was just simply written wrong)."  What you say here is perfectly valid for
the example given, but it is also language specific. VB behaves just as you
say, but a less strongly typed language will not. 

But even keeping the discussion within the domain of VB, sure you get a type
error when you try to pass a string to a routine that wants an integer, so
the class property error handler is not involved, but what about passing an
integer that's outside the acceptable range to a routine that wants an
integer? If MyValue is only allowed to take on values in one (or more)
specific ranges, then you'd better be sure that it keeps within those
bounds, and that's exactly what a property Let method can take care of.

I guess what my point of view boils down to is that it's perfectly ok to
teach programming concepts in itty bitty pieces, but the examples used
should be sufficiently complex to illustrate why the technique being used
*is being used*. That little bit of complexity can make the example seem
more realistic. By building your first class with Let and Get properties the
concepts of data hiding and access control methods are introduced early on,
which is a good thing. After the beginner has "learned the rules" the notion
of what might be gained and lost by bending the rules will make more sense.

Lambert