array() VS Array()

[Tony Marston]

Re: array() VS Array()


"Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
news:pan.2006.0 5.15.21.05.13.9 59574@andyjeffr ies.co.uk...[color=blue]
> On Mon, 15 May 2006 11:58:50 +0100, Tony Marston wrote:[color=green]
>> But if a language allows the same name to mean different things if
>> specified in a different case this could lead to code which is confusing
>> and therefore difficult to maintain. It *should* be the primary objective
>> of every language to avoid such features instead of deliberately
>> implementing them. This is why the GOT verb is frowned upon and excluded
>> from many languages, and why the ALTER verb in COBOL is considered an
>> absolute no-no.
>>
>> In the English language a word has only one meaning regardless of case
>> (such as 'dog', 'Dog' and 'DOG') so why should computer languages be any
>> different?[/color]
>
> Ryan's perfectly valid point aside (different capitalisation of Dog
> meaning different things), I actually don't disagree with you entirely.
> At least not enough to argue about.[/color]

Rubbish. The letters 'd', 'o' and 'g' spell 'dog' and mean the same thing
regardless of case. take the following three sentences:-
1) beware of the dog
2) Beware Of The Dog
3) BEWARE OF THE DOG.

Do these sentences mean the same thing or not? Does the meaning change just
because the case changes?
[color=blue]
> However, I do feel any language ought to be consistent, if the variables
> are case-sensitive the functions should be too. It makes the language a
> lot more predictable in how it will behave.[/color]

I'm afraid that the argument that all computer languages should enforce
case-sensitivity "just to be consistent" is really pathetic. A feature
should not be introduced unless it has genuine benefits, and as the
introduction of case-sensitivity does not solve a problem it is an unwanted
solution.

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Jerry Stuckle]

Re: array() VS Array()

Tony Marston wrote:[color=blue]
> All the while people like you keep harping on about how "politicall y
> correct" it is to introduce even more unnecessary case-sensitivity into
> computer languages I will keep responding with an alternative view. Case
> sensitivity does not solve any problems, therefore it is an unwanted
> solution.
>[/color]

I never said anything about "politicall y correct". I pointed out some real
advantages to having case sensitivity - advantages used by millions of
programmers world-wide.

And here's tony, still a stubborn mule and clinging to th dark ages, refusing to
see advantages because he doesn't want to.

You really are an ass.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Tony Marston]

Re: array() VS Array()


"Gary L. Burnore" <gburnore@datab asix.com> wrote in message
news:e4avo2$qj2 $1@blackhelicop ter.databasix.c om...[color=blue]
> On Mon, 15 May 2006 23:20:58 +0100, "Tony Marston"
> <tony@NOSPAM.de mon.co.uk> wrote:
>[color=green]
>>
>>"Andy Jeffries" <news@andyjeffr ies.co.uk> wrote in message
>>news:pan.2006 .05.15.21.05.13 .959574@andyjef fries.co.uk...[color=darkred]
>>> On Mon, 15 May 2006 11:58:50 +0100, Tony Marston wrote:
>>>> But if a language allows the same name to mean different things if
>>>> specified in a different case this could lead to code which is
>>>> confusing
>>>> and therefore difficult to maintain. It *should* be the primary
>>>> objective
>>>> of every language to avoid such features instead of deliberately
>>>> implementing them. This is why the GOT verb is frowned upon and
>>>> excluded
>>>> from many languages, and why the ALTER verb in COBOL is considered an
>>>> absolute no-no.
>>>>
>>>> In the English language a word has only one meaning regardless of case
>>>> (such as 'dog', 'Dog' and 'DOG') so why should computer languages be
>>>> any
>>>> different?
>>>
>>> Ryan's perfectly valid point aside (different capitalisation of Dog
>>> meaning different things), I actually don't disagree with you entirely.
>>> At least not enough to argue about.[/color]
>>
>>Rubbish. The letters 'd', 'o' and 'g' spell 'dog' and mean the same thing
>>regardless of case. take the following three sentences:-
>>1) beware of the dog
>>2) Beware Of The Dog
>>3) BEWARE OF THE DOG.[/color]
>
> The word god and God have different meanings to some. Does that help?[/color]

The fact that some people choose to apply different meanings is irrelevant.
I am talking about variable and function names in computer languages. Nobody
in their right minds would deliberately create three different variables
such as $foo, $Foo and $FOO as it could create confusion and lead to a
maintenance nightmare. If that isthe case then why should the language allow
that sitatio to be created in the first place?
[color=blue][color=green]
>>Do these sentences mean the same thing or not? Does the meaning change
>>just
>>because the case changes?
>>[color=darkred]
>>> However, I do feel any language ought to be consistent, if the variables
>>> are case-sensitive the functions should be too. It makes the language a
>>> lot more predictable in how it will behave.[/color]
>>
>>I'm afraid that the argument that all computer languages should enforce
>>case-sensitivity "just to be consistent" is really pathetic.[/color]
>
> Of course it is.[/color]

You agree with me? Well, I'll go to the foot of our stairs!

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Tony Marston]

Re: array() VS Array()


"Jerry Stuckle" <jstucklex@attg lobal.net> wrote in message
news:Zeydne3Lr_ 1NvvTZ4p2dnA@co mcast.com...[color=blue]
> Tony Marston wrote:[color=green]
>> All the while people like you keep harping on about how "politicall y
>> correct" it is to introduce even more unnecessary case-sensitivity into
>> computer languages I will keep responding with an alternative view. Case
>> sensitivity does not solve any problems, therefore it is an unwanted
>> solution.
>>[/color]
>
> I never said anything about "politicall y correct". I pointed out some
> real advantages to having case sensitivity - advantages used by millions
> of programmers world-wide.[/color]

What you are saying is that just because YOU use case-sensitivity in a
particular way in want the rest of the world to do exactly the same, and not
only that you want the language changed in such a way that other choices are
impossible.
[color=blue]
> And here's tony, still a stubborn mule and clinging to th dark ages,
> refusing to see advantages because he doesn't want to.
>
> You really are an ass.[/color]

That's just your opinion. My opinion is that being able to create variables
such as $foo, $Foo and $FOO which actually mean DIFFERENT things is a bad
idea as it be confusing and lead to a maintenance nightmare. If that is the
case then the language should not allow it. It is the prospect of
maintenance nightmares, of allowing programmers to "shoot themselves in the
foot", which caused the GOTO verb never to be implemented in PHP and its
proposed introduction by those who think it is "clever" to be resisted.

Case-sensitivity never solved any problem, so why is it a solution?

--
Tony Marston

http://www.tonymarston.net

http://www.radicore.org

[Andy Jeffries]

Re: array() VS Array()

On Mon, 15 May 2006 23:20:58 +0100, Tony Marston wrote:[color=blue][color=green]
>> However, I do feel any language ought to be consistent, if the variables
>> are case-sensitive the functions should be too. It makes the language a
>> lot more predictable in how it will behave.[/color]
>
> I'm afraid that the argument that all computer languages should enforce
> case-sensitivity "just to be consistent" is really pathetic. A feature
> should not be introduced unless it has genuine benefits, and as the
> introduction of case-sensitivity does not solve a problem it is an
> unwanted solution.[/color]

I didn't say *all* computer languages, don't put words in my mouth.
Either that or your misread my intention.

If a language is case-sensitive for variable names and class members it
should also be consistent in that it's case-sensitive for functions and
class methods.

I'm not saying all languages should be case-sensitive, just that if one is
partially case-sensitive it should be consistently case-sensitive within
itself.

To be honest, I couldn't give a crap if Cobol, Haskell or C#/.Net is
case-sensitive, I'm a PHP programmer (at the moment) and would like my
number 1 language to be consistent.

Cheers,


Andy


--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

[Andy Jeffries]

Re: array() VS Array()

On Mon, 15 May 2006 23:14:22 +0100, Tony Marston wrote:[color=blue][color=green]
>> And, as others have pointed out, use all caps anything defined as a
>> CONSTANT. That way you know it's a constant.[/color]
>
> In PHP it is not a requirement that a constant be defined in upper case.
> It is easy to tell the difference between a constant and a variable as one
> has a leading '$' while the other does not. Which of these two is the
> constant - FOO or $FOO?[/color]

FOO could be either a constant or a reference to a function. This is
where consistent capitalisation helps clarify:

<?php
function FOO()
{
print "bar";
}

$foo = FOO;

$foo();

?>

Cheers,



Andy


--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

[Richard Levasseur]

Re: array() VS Array()

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. 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. 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.

(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. 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

Re: Function case
1) It would be nice to have consistancy throughout the language.
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. I declare it as 'myFunc', and its stored as
'myfunc,' but i naturally expect it to match the way I wrote it. 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. Making it 'fuzzy' sounds sloppy and
doesn't, in my opinion, promote good coding habits. 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. 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_s ql() has a different authority to it than
Hack_Together_S QL(). 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.

Re: maintainance nightmare
You've not seen some of the 'professional' PHP code out there you can
buy? Half of them don't even spell variable names right, let alone
adhere to any sort of standard or continuity. I'd much rather pick up
any code and understand the intent of it instead of being able to skip
pressing the shift key.

Of course, thats just how I see things.

[Tony Marston]

Re: array() VS Array()


"Richard Levasseur" <richardlev@gma il.com> wrote in message
news:1147767617 .862820.105770@ j33g2000cwa.goo glegroups.com.. .[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

There is no such meaing in any language that I have used. It is just a
variable.
[color=blue]
> 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.[/color]

That is not a standard of the language, it is merely a convention adopted by
some programmers.
[color=blue]
> (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.[/color]

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 "traditiona lly" 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.
[color=blue]
> 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[/color]

That terminology does not exist in PHP, so your arguments do not apply.
[color=blue]
> Re: Function case
> 1) It would be nice to have consistancy throughout the language.[/color]

Perpetuating a bad idea just to be "consistent " does not sound very clever
to me.
[color=blue]
> 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.[/color]

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?
[color=blue]
> I declare it as 'myFunc', and its stored as
> 'myfunc,' but i naturally expect it to match the way I wrote it.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Making it 'fuzzy' sounds sloppy and
> doesn't, in my opinion, promote good coding habits.[/color]

Fuzzy spelling would be bad, but in my experience fuzzy case does not make a
blind bit of difference.
[color=blue]
> 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.[/color]

That is a personal preference, not a feature of the language. Other people
have their own personal preferences.
[color=blue]
> 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_s ql() has a different authority to it than
> Hack_Together_S QL().[/color]

Are you saying that you would deliberately create two different functions
called hack_together_s ql() and Hack_Together_S QL()? If you did that on any f
my projects I would fire you on the spot.
[color=blue]
> 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.[/color]

That "imortance" only exists in your mind. It has no significance whatsoever
to the computer language.
[color=blue]
> Re: maintainance nightmare
> You've not seen some of the 'professional' PHP code out there you can
> buy?[/color]

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.
[color=blue]
> Half of them don't even spell variable names right, let alone
> adhere to any sort of standard or continuity.[/color]

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.
[color=blue]
> I'd much rather pick up
> any code and understand the intent of it instead of being able to skip
> pressing the shift key.[/color]

In a case-insensitive language the shift key becomes irrelevant.
[color=blue]
> Of course, thats just how I see things.[/color]

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