Posted by Tony Marston on 05/18/06 11:02

"Richard Levasseur" <richardlev@gmail.com> wrote in message
news:1147767617.862820.105770@j33g2000cwa.googlegroups.com...
> RE: Variable case
> Traditionally,
> FOO is read as a global literal constant, you cannot change this and is
> available everywhere and is intended to be used both inside and outside
> the project.
> $FOO, $foo, $Foo can be read in wildly different ways. By and large i
> see:
>
> $FOO as a global variable for a specific application.

Not in any language I have used, it isn't. In PHP $FOO is a local variable.
$GLOBALS['FOO'] is a global variable. In my previous language a loal
variable was defined using $name$ while a global variable used $$name. Th
case was irrelevant, it was where the $ signswere placed that
wassignificant.

> Usually because
> you can't pre-initialize it in the class or without doing something
> before hand, and typically you don't change these, they're a
> honor-system read only.
> $foo is a local variable, something that only exists within the current
> scope and goes away later.
> $Foo i rarely see, though usually it means its important for some
> reason, such as some sort of glue between a function and something
> outside the function, or a reference to something within another
> something-something.

There is no such meaing in any language that I have used. It is just a
variable.

> The point is it doesn't quite adhere to the
> locality of $foo but isn't as off limits and viewable as $FOO; I like
> to think of it as akin to 'protected' in OOP terminology. Occasionally
> I see important public methods starting with a capital and using camel
> notation, such as functions that should be called during shutdown or
> startup prior to any other calls.

That is not a standard of the language, it is merely a convention adopted by
some programmers.

> (Aside, this is one reason i like how perl differentiates uses with $,
> #, and @, it gives me a better understanding of what context it should
> be used and read in)
>
> So, yes, traditionally, case does have an impact on the implied meaning
> of what a variable does, where it is used, and so forth.

I dispute your use of the word "traditionally". The "original" programing
languages (i'm talking Assember, COBOL, Fortran) gave absolutely no
significance to case at all, and neither did any other language I have used
right up to the 21st century. So "traditionally" in computer languages case
has been totally insignificant, it is only in a few modern languages that it
has been introduced. That was a bad move, IMHO.

> You can have
> case insensitivity when there are language constructs that strictly
> limit how a variable is used. 'local refererence constant $foo;
> global copy variable $FOO; bridging constant local $Foo' etc etc

That terminology does not exist in PHP, so your arguments do not apply.

> Re: Function case
> 1) It would be nice to have consistancy throughout the language.

Perpetuating a bad idea just to be "consistent" does not sound very clever
to me.

> Previously, classes were stored in all lowercase, and later this was
> changed to match the declared case. (Thank god!)
> 2) You know what to expect when you are looking for a function or
> declared identifier.

What would your reaction be if you looked through the manual for a function
only tofid that it existed several times, each with a different combination
of case, and each with a different meaning? Wold this be a good idea or not?
If not, then why sould the language allow it?

> I declare it as 'myFunc', and its stored as
> 'myfunc,' but i naturally expect it to match the way I wrote it.

But if case is insignifiant it does not mean that you have to reference it
in exactly the same case as it was defined. Spelling is significant case
should not be.

> Now I
> have to write case insensitivity into determining if its the function i
> want, and to verify that whatever information i'm storing is, indeed
> correct? Rubbish i say.
> If i call it myfunc, MYFUNC, or MyFuCn, i expect to be able to refer to
> it only as how i defined it.

Why? In all the languages I have used in the past I could use any case I
wanted to reference that function or variable. Case is insignificant, only
the spelling is important.

> Making it 'fuzzy' sounds sloppy and
> doesn't, in my opinion, promote good coding habits.

Fuzzy spelling would be bad, but in my experience fuzzy case does not make a
blind bit of difference.

> I'd much rather
> have an error handler catch a programming mistake than the computer
> assume it knew what i meant.
> 3) If i call it MYFUNC, i'm capitalizing it for a reason.

That is a personal preference, not a feature of the language. Other people
have their own personal preferences.

> Calling it
> as myfunc() is not what i am expecting to look for in code if i go
> reading it over and downplays the importants that this function must
> server. hack_together_sql() has a different authority to it than
> Hack_Together_SQL().

Are you saying that you would deliberately create two different functions
called hack_together_sql() and Hack_Together_SQL()? If you did that on any f
my projects I would fire you on the spot.

> The former tends to imply that its a hack and
> shouldn't be relied on, the latter that it is some complicated
> necessity to be used with caution, and the importance of both of those
> meanings should always be present in the writing of them.

That "imortance" only exists in your mind. It has no significance whatsoever
to the computer language.

> Re: maintainance nightmare
> You've not seen some of the 'professional' PHP code out there you can
> buy?

I have been programming for over 20 years and I've seen a enormous amount of
crap code. I have also seen an enormous amount of crap standards which
forces programmers to write crap code.

> Half of them don't even spell variable names right, let alone
> adhere to any sort of standard or continuity.

If a variable is mis-spelled then it will cause an error that should be
picked up in testing. The trouble with standards is that there is no
standard. Each group has its own standards, and they are all different.

> I'd much rather pick up
> any code and understand the intent of it instead of being able to skip
> pressing the shift key.

In a case-insensitive language the shift key becomes irrelevant.

> Of course, thats just how I see things.

Your view on this issue is not the same as my view, yet to want to change
the world to conform to your view. I am simply speaking against those
changes.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

[Back to original message]