[AccessD] 16 bit Integer bad practice

DWUTKA at marlow.com DWUTKA at marlow.com
Wed May 18 14:50:34 CDT 2005


Actually, if a boolean is true or not is a logic function.  

Drew

-----Original Message-----
From: Scott Marcus [mailto:marcus at tsstech.com]
Sent: Wednesday, May 18, 2005 2:38 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] 16 bit Integer bad practice


And to test if something is true or not all happens with math. So why
not make each Boolean a long instead?

Your reasoning does not hold water. One should use appropriate variable
types to store their data.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Wednesday, May 18, 2005 3:09 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] 16 bit Integer bad practice

No, because a boolean variable is designed for checking if something is
true
or not.  It's not used to perform a math function, or to count up a
loop.

Drew

-----Original Message-----
From: Scott Marcus [mailto:marcus at tsstech.com]
Sent: Wednesday, May 18, 2005 12:49 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] 16 bit Integer bad practice


Drew,

Less efficient because they are 16 bit does not make them bad practice.
It makes them slower.

Let's take this to an extreme, should I set up a long and pack all my
Booleans into that so that they take up less space (efficient)?
Certainly Not. 

You have gone off the deep end.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Wednesday, May 18, 2005 11:06 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable

I disagree there. There is no valid reason that makes Global Variables
bad
in any way, unless they are used for something other then what their
scope
is designed for.  However, Integers, while they may be misused, even if
they
are used correctly, they are still bad practice, because they are 16 bit
variables.  

Drew

-----Original Message-----
From: Scott Marcus [mailto:marcus at tsstech.com]
Sent: Wednesday, May 18, 2005 6:20 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Global Variable


<<P.S.-- Still doesn't make Globals bad practice, only misuse of
<<globals...which is still my position.

And like wise, use of Integer is not bad practice, only misuse...

Scott Marcus

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 2:40 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable

Ah.  There's the issue.  'If a global doesn't need to be SET by project
wide
code'.  Okay.  Now, that I will back down on.  I personally don't have
an
issue with setting it one place, and using it other places.  No problem
there.  But what if you are constantly using (reading and writing) it
from
many places in your project.  Does a Global Variable fit the model?  Of
course!  Honestly, I use classes too, and will make read only properties
'read only'.

Drew

P.S.-- Still doesn't make Globals bad practice, only misuse of
globals...which is still my position.



-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, May 17, 2005 11:52 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


I understand completely Drew.  In order to not use globals you have to
THINK
and you are too busy typing to do that.

Correct me if I am wrong, but nowhere did I advocate any code like you
mentioned.  Can you show me where in my email I advocated that?  What I
said
was that if a global doesn't need to be SET by project wide code then it
doesn't need to be global.

I have seen in your previous posts where you mention saving keystrokes.
Understand that I am NOT a data entry person.  My job is to design well
engineered systems.  If that means more keystrokes, so be it.  

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 17, 2005 11:32 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Tighter?  If I looked at code like this:

Dim MyModuleLevelString as String
Private Function SetModuleLevelString(strValueToSet As String)
MyModuleLevelString=strValueToSet End Function

I would think the developer was getting paid by the key stroke.....not
that
it was 'tight code'.

Drew

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, May 17, 2005 6:59 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Global Variable


Gustav,

This is nothing new, and not something I take credit for figuring out.
It
is not uncommon when you work with classes to have methods set the
values of
and return the values from class properties.  In fact with classes you
have
syntax constructs specifically for this - property get/set/let.  You
can, if
you wish, dim a variable public in the class header and then it is just
read
/ write to anyone with a pointer to the class.  Or you use a property
get
and or set/let in whatever combination you need.  A read-only value has
only
a property get.  A Write-only has only a property set (not very common)
and
a read / write has a property get and property let/set.

The objective is simply to control how the variable is read/written.
Since
the variable is dimensioned private to the module (or class), only a
function in the module or class can set the value, and only a function
in
the module or class can return the value.  To make a property "read
only",
create only a function that returns the value, but do not build a
function
that sets the value.  Then only the class or module itself can set the
variable.  

For example as the module initializes, perhaps some value is pulled from
a
table and written into the variable.  Then a function returns the value
to
any process that needs the value.  Or perhaps the value is calculated by
some math transformation using other values in other variables.  The
><DEFANGED.0 ><DEFANGED.135 ><DEFANGED.5 other
variables are set by processes, but in order to read out the value, a
function either returns the variable directly or returns the value of
the
mathematical transformation using the values in the other variables.

This is not new stuff, I did not invent it, but it is commonly used to
"replace" global variables such that the CONCEPT of a global variable
exists
(can be seen from anywhere) but still protects the variable from being
written when it shouldn't be or by processes that should not be able to
write to the variable.

And yes, it is more work.  It is just one of those things that you do or
your don't.  If you accept the practice, then you start thinking about
protecting variables, using variable scope, and using functions to set /
return values where appropriate.  It becomes habit and your code becomes
a
little bit tighter.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 17, 2005 6:30 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Global Variable


Hi John

Well, here we have full control on where functions put their nasty
fingers.

I haven't managed yet to build self generating code; to some this would
indicate a brave new world, to some it would be a nightmare - functions
creeping around and attacking our globals and eating our children...
gosh.
But worse, they would soon learn how to take advantage of your functions
to
change those "private variables"! Be prepared.

/gustav

>>> jwcolby at colbyconsulting.com 05/16 10:58 pm >>>

..  Making this a global allows functions
that have no business setting these variables to change them.  By having
a
private variable returned by a public function, any function that needs
the
information can get it but cannot modify it.

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

 




NOTICE:  This electronic mail transmission is for the use of the named
individual or entity to which it is directed and may contain information
that is privileged or confidential.  If you are not the intended
recipient,
any disclosure, copying, distribution or use of the contents of any
information contained herein is prohibited.  If you have received this
electronic mail transmission in error, delete it from your system
without
copying or forwarding, and notify the sender of the error by replying
via
email or by calling TSS Technologies at (513) 772-7000, so our address
record can be corrected.   

Any information included in this email is provided on an "as is" and
"where
is" basis, and TSS Technologies makes no representations or warranties
of
any kind with respect to the completeness or accuracy of the information
contained in this email, or with respect to any other matters
communicated
in this email.  TSS Technologies hereby disclaims any and all express or
implied warranties of any kind.  Nothing in this email shall be
construed to
create any kind of contractual or binding agreement or commitment by or
on
behalf of TSS Technologies, Inc., the recipient, or any third-parties.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
This message has been 'sanitized'.  This means that potentially
dangerous content has been rewritten or removed.  The following
log describes which actions were taken.

Sanitizer (start="1116415591"):
  Split really long tag (over 2k):
      >>_P.S.-- Still doesn't mak ...  in other variables. The<<
  Total modifications so far: 1


Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.4 2004/04/21 20:24:38 dpuryear Exp $
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

 




NOTICE:  This electronic mail transmission is for the use of the named
individual or entity to which it is directed and may contain information
that is privileged or confidential.  If you are not the intended
recipient,
any disclosure, copying, distribution or use of the contents of any
information contained herein is prohibited.  If you have received this
electronic mail transmission in error, delete it from your system
without
copying or forwarding, and notify the sender of the error by replying
via
email or by calling TSS Technologies at (513) 772-7000, so our address
record can be corrected.   

Any information included in this email is provided on an "as is" and
"where
is" basis, and TSS Technologies makes no representations or warranties
of
any kind with respect to the completeness or accuracy of the information
contained in this email, or with respect to any other matters
communicated
in this email.  TSS Technologies hereby disclaims any and all express or
implied warranties of any kind.  Nothing in this email shall be
construed to
create any kind of contractual or binding agreement or commitment by or
on
behalf of TSS Technologies, Inc., the recipient, or any third-parties.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
This message has been 'sanitized'.  This means that potentially
dangerous content has been rewritten or removed.  The following
log describes which actions were taken.

Sanitizer (start="1116439415"):
  Split really long tag (over 2k):
      >>_P.S.-- Still doesn't mak ...  in other variables. The<<
  Total modifications so far: 1


Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.4 2004/04/21 20:24:38 dpuryear Exp $
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

 




NOTICE:  This electronic mail transmission is for the use of the named
individual or entity to which it is directed and may contain information
that is privileged or confidential.  If you are not the intended recipient,
any disclosure, copying, distribution or use of the contents of any
information contained herein is prohibited.  If you have received this
electronic mail transmission in error, delete it from your system without
copying or forwarding, and notify the sender of the error by replying via
email or by calling TSS Technologies at (513) 772-7000, so our address
record can be corrected.   

Any information included in this email is provided on an "as is" and "where
is" basis, and TSS Technologies makes no representations or warranties of
any kind with respect to the completeness or accuracy of the information
contained in this email, or with respect to any other matters communicated
in this email.  TSS Technologies hereby disclaims any and all express or
implied warranties of any kind.  Nothing in this email shall be construed to
create any kind of contractual or binding agreement or commitment by or on
behalf of TSS Technologies, Inc., the recipient, or any third-parties.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
This message has been 'sanitized'.  This means that potentially
dangerous content has been rewritten or removed.  The following
log describes which actions were taken.

Sanitizer (start="1116445545"):
  Split really long tag (over 2k):
      >>_P.S.-- Still doesn't mak ...  in other variables. The<<
  Total modifications so far: 1


Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.4 2004/04/21 20:24:38 dpuryear Exp $



More information about the AccessD mailing list