PRIVATE variables (was parameters) 
Author Message
 PRIVATE variables (was parameters)

Jon and several other people stated that they do not use PRIVATE variables.
Why is this?  I only want variables that that are actually declared in a
code block to be available to that code block.  I always use PRIVATE
variables instead of LOCAL becuase they are the most tightly (is that the
right word?) scoped.  I will never get a name collision with identifiers in
other blocks of code in the same source file.  I am not imaginitive enough
to make up a new name for every array index or accumulator variable that I
use.  lnCtr1, lnCtr2, lnCtr3, ... or lnTotal is about all that I can handle.
I rarely (as I said previously) use PUBLIC variables, so getting mixed up
with those is not a concern, plus I have another way of handling that
problem.

I use Polish notation that includes an extra character to indicate scope.
That way I avoid mixups between local and global identifiers.  It goes sorta
like this -

For a global character variable I name it gcSomeChar
For a local (read PRIVATE) character varibale I name it lcSomeChar
For a parameter character variable I name it pcSomeChar

I have never had to waste time trying to debug code that won't work because
of conflicting identifier names, but maybe I am missing out on some other
benefit.  Will someone elighten me?

--
Dave Holden
Holden Consulting
Abbotsford, BC, Canada



Tue, 01 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

> Jon and several other people stated that they do not use PRIVATE
> variables. Why is this? I only want variables that that are actually
> declared in a code block to be available to that code block. I always use
> PRIVATE variables instead of LOCAL becuase they are the most tightly (is
> that the right word?) scoped.

PRIVATEs have tighter scope that LOCALs? Interesting. Can you give an
example of what you mean?

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Tue, 01 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

>Jon and several other people stated that they do not use PRIVATE variables.
>Why is this?  I only want variables that that are actually declared in a
>code block to be available to that code block.  I always use PRIVATE
>variables instead of LOCAL becuase they are the most tightly (is that the
>right word?) scoped.  I will never get a name collision with identifiers in
>other blocks of code in the same source file.  I am not imaginitive enough
>to make up a new name for every array index or accumulator variable that I
>use.  lnCtr1, lnCtr2, lnCtr3, ... or lnTotal is about all that I can handle.
>I rarely (as I said previously) use PUBLIC variables, so getting mixed up
>with those is not a concern, plus I have another way of handling that
>problem.

>I use Polish notation that includes an extra character to indicate scope.
>That way I avoid mixups between local and global identifiers.  It goes sorta
>like this -

>For a global character variable I name it gcSomeChar
>For a local (read PRIVATE) character varibale I name it lcSomeChar
>For a parameter character variable I name it pcSomeChar

>I have never had to waste time trying to debug code that won't work because
>of conflicting identifier names, but maybe I am missing out on some other
>benefit.  Will someone elighten me?

Dave... uh... everybody will scream at me but the best way I can explain it is
"that thread you're referencing" was one of the dorkier I've read.

From a "hey Clipper is the best thing on Earth" standpoint I suppose anything
can be argued but there are in reality lots of things "wrong" with the
language.  The attempt to clean up some of the things added for "dBASE
compatibility" began with Nantucket's release of 5.0 but they had to go slow
to not upset the installed base of code (and coders.)

There are excellent reasons to avoid global variables (that would be PUBLIC
declarations) and semi-global (that would be PRIVATE declarations.)  Most of
the reasons have to do with "safety" i.e. "knowing for a fact what will occur"
and PRIVATE variables break that trust (as obviously PUBLICs do.)

It doesn't matter if you have a particularly hard time coming up with variable
names... language issues aren't normally decided on the basis of things like
that.  Clearly everybody shouldn't be penalized because a few people can't
think up some names.

It is possible that you've just reversed your understanding of variable
declarations since it is LOCAL that have the restricted scope and PRIVATE
which does not.

Somebody posted "I only use PRIVATE vars when I want to macro them" and they
don't understand that you can macro a LOCAL var as easily as a PRIVATE.

Other people post "sometimes you have to access variables globally" and of
course you do.  In Clipper as in every other language however there is a safe
way to do it and a "let's just declare a PUBLIC variable" way to do it.

If you wrote a "get/set" function (called a "property" in Delphi and VB) you
can both read and write what amounts to a PUBLIC variable but it is a STATIC
variable hidden within a function which controls access.  Why?  Uhh... safety.

You can't accidentally assign a logical to PUBLIC num where num was a numeric
most of it's life.  You can't RELEASE num.  You can't declare a PRIVATE num in
a routine and lose site of your PUBLIC num.

All the things that people who design languages try and solve by introducing
new languages (Java for instance) are dismissed by those that will (10 years
of experience later) suggest that somebody ought to do something about.  Or
they will post how they just spent a week debugging some terrible crud that
somebody else wrote.  The point is to design languages that don't permit all
sorts of terrible crud.

Here I've got a couple of quiz questions.

  PRIVATE nMax

  nMax := 10

  WHILE nMax > 0
        ? TomsLibraryFunction()
       --nMax
  ENDDO

How many times will you see the output of my library function?  The answer is
not 10 or 11 or 9 or 5.

The next question is what is wrong with the pass by reference mechanism in
Clipper that pass by reference in other languages don't suffer?

And for a bonus point... C has global references... why are they not as bad as
Clipper globals?

You also aren't using Polish notation unless you push the operands onto the
stack before you call the arithmetic operators.  5 1 + is reverse Polish
notation and the answer is 6.

You are referring to Hungarian Notation, named after Charles Simonyi a
programmer at Microsoft who is apparently of Hungarian extraction.

My advice is, if you can't deal with languages that don't permit things like
PUBLIC and PRIVATE variables and the macroing of command words you will find
yourself programming in Clipper for the rest of your life.  Nobody else does
it because despite it sounding like they are incredibly good ideas they cause
more problems than they solve.

I look forward to your answers on the quiz.

Tom

---> Learn a little something at http://www.leylan.com - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

> My advice is, if you can't deal with languages that don't permit things
> like PUBLIC and PRIVATE variables and the macroing of command words you
> will find yourself programming in Clipper for the rest of your life.

The last time I checked the macro compiler in CA-Clipper didn't allow the
compilation of commands.

Quote:
> Nobody else does it because despite it sounding like they are incredibly
> good ideas they cause more problems than they solve.

Good idea or not (you should know what I think) it is incorrect to suggest
that no other languages have such scopes available for their variables and
that no other languages has the ability to compile itself at run-time. I
know you probably know this but the statement "nobody else does it" is a
little too final and very wrong.

Not that this really detracts from the main thrust of your post.

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)
I noticed that many have the most excellent reasons to use or not to
use privates (or worse: publics), but I would like to know if the
disadvantages are bigger than the benefits, specially when we talk
about one otr two small arrays that has to be available in all modules
of the aplication.

Another example: If I use achoice:
achoice(top,left,bottom,right,array,"UDF")
I can't pass any vars as parameters to the UDF (beside the default
ones) so if I want to use the values of the array inside the UDF, the
array has to be private. So far for people that 'never' use privates.
Now you can stop using achoice (long live tbrowse) but sometimes it
makes live more easy. You can also stop using Clipper.

Now what about vars that are used in #command or #translate in
headerfiles? My de{*filter*} sees them all as privates. Are they released
automatically? I can't define vars as local in a headerfile.

Paul Kramer

Sent via Deja.com http://www.*-*-*.com/
Share what you know. Learn what you don't.



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)
Sorry, I have got them backwards.  I am fairly new to Clipper programming
and I have not mastered the language.  That is why I subscribed to this NG.
So I can learn from others with more experience than me.

Dave Holden


Quote:
> On Fri, 16 Jul 1999 23:15:27 GMT, Dave Holden

> > Jon and several other people stated that they do not use PRIVATE
> > variables. Why is this? I only want variables that that are actually
> > declared in a code block to be available to that code block. I always
use
> > PRIVATE variables instead of LOCAL becuase they are the most tightly (is
> > that the right word?) scoped.

> PRIVATEs have tighter scope that LOCALs? Interesting. Can you give an
> example of what you mean?

> --
> Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
> http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
> http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for
Windows.
> Free software, including........| dgscan - DGROUP scanner for Clipper.



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

>The last time I checked the macro compiler in CA-Clipper didn't allow the
>compilation of commands.

Well that is good news <g>

Quote:
>> Nobody else does it because despite it sounding like they are incredibly
>> good ideas they cause more problems than they solve.

>Good idea or not (you should know what I think) it is incorrect to suggest
>that no other languages have such scopes available for their variables and
>that no other languages has the ability to compile itself at run-time. I
>know you probably know this but the statement "nobody else does it" is a
>little too final and very wrong.

I know where you're coming from on these things... nobody (well I use the
'grand' definition of "nobody") disputes the need to determine some things at
runtime or to execute conditional code.  I'm preaching to the choir of course
but it is the mechanism implemented to do it, not the need that causes the
problems.

We'd have retained computed GOTO's as they had in COBOL and I'm quite certain
in interpreted BASIC if they had proven to be the solution rather than the
causes of even more trouble.

Specifically in C and in all the OOPs languages that I'm aware of (there
are plenty I'm not aware of) the global variables aren't visible unless the
person who declared it makes it visible.  There is a difference between
referencing a global variable and accidentally clobbering one.

Clipper's implementation permits clobbering and no programmer is aware of
it unless it is dramatic enough to be noticed.

Anyway... I know what you mean.

Tom

---> Learn a little something at http://www.leylan.com - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

>I noticed that many have the most excellent reasons to use or not to
>use privates (or worse: publics), but I would like to know if the
>disadvantages are bigger than the benefits, specially when we talk
>about one otr two small arrays that has to be available in all modules
>of the aplication.
>Another example: If I use achoice:
>achoice(top,left,bottom,right,array,"UDF")
>I can't pass any vars as parameters to the UDF (beside the default
>ones) so if I want to use the values of the array inside the UDF, the
>array has to be private. So far for people that 'never' use privates.
>Now you can stop using achoice (long live tbrowse) but sometimes it
>makes live more easy. You can also stop using Clipper.
>Now what about vars that are used in #command or #translate in
>headerfiles? My de{*filter*} sees them all as privates. Are they released
>automatically? I can't define vars as local in a headerfile.

Paul,

I generalize a lot (people are groaning) but there is a reason for that.  Any
sufficiently complex system needs to be simplified just to understand it.  So,
generally, "NO" the disadvantages do not outweigh the benefits.

The benefits (if you listed them) include many things people don't list.  The
benefits aren't always intuitively obvious.  The disadvantages are not always
recognized as "problems" because the person who caused them has gone off
somewhere else (presumably) to save time and money for somebody else.

Regardless of the language used a common set of needs exists.  Accessing
global data is a common need.  The question is then how best to do it, i.e.
how to cause the fewest problems while filling the need.

In the hopes of broadening some people's "view" of the state of Clipper
programming and computer programming in general let me start off with "of
course you can pass additional parameters to ACHOICE() far in excess of the
default ones.

Write a function called "SuperAChoice()" and pass all the regular parameters
along with as many others that you wish were in ACHOICE() itself.  Let
SuperAChoice() setup references to any external data you need and then have it
call ACHOICE().

In this way (should you still require a PRIVATE variable) you've pushed down
the chain isolating it from the "application code" by another level.  Now if
you could ever find the time to convert from ACHOICE() to TBROWSE you would go
to SuperAChoice(), make the modifications there and what do you know all those
ACHOICE() routines are now TBROWSE routines.

Reduce the problems don't build upon them.

Finally, what "vars" in #command and #translate what are doing that for?

Tom

---> Learn a little something at http://www.*-*-*.com/ - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)
I NEVER use publics or privates in my code. Obviously, I do have need for "global"
information. I have a program (global.prg - duh!) where I explicitly create static
variables, including arrays.
I can send:
    SetGlobal( "GLOBAL_NAME" , xVALUE )
and  receive.
    xVal:= GetGlobal( "GLOBAL_NAME" )
Works very well for me, as all "global" data is well documented and comes from one place.
Quote:


> >I noticed that many have the most excellent reasons to use or not to
> >use privates (or worse: publics), but I would like to know if the
> >disadvantages are bigger than the benefits, specially when we talk
> >about one otr two small arrays that has to be available in all modules
> >of the aplication.

> >Another example: If I use achoice:
> >achoice(top,left,bottom,right,array,"UDF")
> >I can't pass any vars as parameters to the UDF (beside the default
> >ones) so if I want to use the values of the array inside the UDF, the
> >array has to be private. So far for people that 'never' use privates.
> >Now you can stop using achoice (long live tbrowse) but sometimes it
> >makes live more easy. You can also stop using Clipper.

> >Now what about vars that are used in #command or #translate in
> >headerfiles? My de{*filter*} sees them all as privates. Are they released
> >automatically? I can't define vars as local in a headerfile.

> Paul,

> I generalize a lot (people are groaning) but there is a reason for that.  Any
> sufficiently complex system needs to be simplified just to understand it.  So,
> generally, "NO" the disadvantages do not outweigh the benefits.

> The benefits (if you listed them) include many things people don't list.  The
> benefits aren't always intuitively obvious.  The disadvantages are not always
> recognized as "problems" because the person who caused them has gone off
> somewhere else (presumably) to save time and money for somebody else.

> Regardless of the language used a common set of needs exists.  Accessing
> global data is a common need.  The question is then how best to do it, i.e.
> how to cause the fewest problems while filling the need.

> In the hopes of broadening some people's "view" of the state of Clipper
> programming and computer programming in general let me start off with "of
> course you can pass additional parameters to ACHOICE() far in excess of the
> default ones.

> Write a function called "SuperAChoice()" and pass all the regular parameters
> along with as many others that you wish were in ACHOICE() itself.  Let
> SuperAChoice() setup references to any external data you need and then have it
> call ACHOICE().

> In this way (should you still require a PRIVATE variable) you've pushed down
> the chain isolating it from the "application code" by another level.  Now if
> you could ever find the time to convert from ACHOICE() to TBROWSE you would go
> to SuperAChoice(), make the modifications there and what do you know all those
> ACHOICE() routines are now TBROWSE routines.

> Reduce the problems don't build upon them.

> Finally, what "vars" in #command and #translate what are doing that for?

> Tom

> ---> Learn a little something at http://www.*-*-*.com/ - Now with "Quote for the Day"



Wed, 02 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

>We'd have retained computed GOTO's as they had in COBOL and I'm quite certain

That's a fortran feature, not found in COBOL.


Thu, 03 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:


>>We'd have retained computed GOTO's as they had in COBOL and I'm quite certain

>That's a FORTRAN feature, not found in COBOL.

Shoot... there goes 10 years of retaining that piece of information down the
drain.

Thanks,

Tom

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Thu, 03 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

> Specifically in C and in all the OOPs languages that I'm aware of (there
> are plenty I'm not aware of) the global variables aren't visible unless
> the person who declared it makes it visible. There is a difference between
> referencing a global variable and accidentally clobbering one.

Yes, that's the difference between what I'd (incorrectly?) refer to as a
"static" languages and "dynamic" languages. Thankfully (to include the topic
of this newsgroup) Clipper can, to an extent, pretend to be both.

Quote:
> Clipper's implementation permits clobbering and no programmer is aware of
> it unless it is dramatic enough to be noticed.

Or they use the right command line switches on the compiler.

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Fri, 04 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

> Another example: If I use achoice:
> achoice(top,left,bottom,right,array,"UDF")
> I can't pass any vars as parameters to the UDF (beside the default
> ones) so if I want to use the values of the array inside the UDF, the
> array has to be private. So far for people that 'never' use privates.
> Now you can stop using achoice (long live tbrowse) but sometimes it
> makes live more easy. You can also stop using Clipper.

I don't quite follow this. If you've gone to the trouble of writing your own
array browsing function then why not use it from then on. Hand crafting a
TBrowse each time (as you see to be suggesting, apologies if I've missed
your point) is the hard way of doing things.

To write your own custom and extensible AChoice() replacement isn't to "stop
using Clipper" (if you get my meaning) but is to *start* using Clipper.

Quote:
> Now what about vars that are used in #command or #translate in
> headerfiles?

What variables in #commands and #translates?

--
Take a look in Hagbard's World: |   w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ |     eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ |    weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.



Fri, 04 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)
On Fri, 16 Jul 1999 23:15:27 GMT, "Dave Holden"

<snip>

Quote:
>I use Polish notation that includes an extra character to indicate scope.

<PEDANT>

That coding style is actually called Hungarian notation, after Charles
Simonyi.

</PEDANT>

--
Nick Ramsay
WitzEnd Computer Services



Fri, 04 Jan 2002 03:00:00 GMT  
 PRIVATE variables (was parameters)

Quote:

>Yes, that's the difference between what I'd (incorrectly?) refer to as a
>"static" languages and "dynamic" languages. Thankfully (to include the topic
>of this newsgroup) Clipper can, to an extent, pretend to be both.

<I wrote>

Quote:
>> Clipper's implementation permits clobbering and no programmer is aware of
>> it unless it is dramatic enough to be noticed.
>Or they use the right command line switches on the compiler.

I'm not entirely certain of that.  A properly declared PUBLIC variables in
MAIN.PRG with a MEMVAR <publicvar> will be clobbered by PUBLIC variable
similarly defined in MYLIB.LIB won't it?

To clarify the "half-truth" I wrote earlier, the advantage of C is that in
order to clobber the global variable you would have to know it's name (you
can't do it accidentally) and the programmer doing the clobbering would have
to EXTERN it.  It can't be an accident... you wouldn't EXTERN your own global
variables.

A "let me see these GLOBALS" declaration is an admission that you know they
exist.

tom

---> Learn a little something at http://www.leylan.com
---> Now in French, German, Italian, Portuguese and Spanish



Fri, 04 Jan 2002 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Lots of Public and Private variables - no penalties on modern PC.

2. Public\private memory variables

3. Private variables can be changed outsid e?

4. Private variables can be changed outside?

5. Making Instace Variables Private/Local

6. Private instance variables

7. private variables

8. private variables (again)

9. private variable

10. cant see PRIVATE variable in MODULE SUBROUTINE when debugging with IFC/IDB v7.1

11. Accessing private variable as pointer

12. Private variables in Visual Studio

 

 
Powered by phpBB® Forum Software