Hi Cynic:
"Cynic" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I'm ++1 on making PHP 100% case-sensitive. I just hate to see
MySQL_Connect(),
> MYSQL_Connect(), mySQL_DB_Query(), etc., in other people's source. It
makes it
> hard to read. It also makes the namespace much much smaller.
Actually, if they keep it case-insensitive, a tool to clean up the function
calls to match the function declaration might be useful. Of course
something like this couldn't be done if it's made case-sensitive. I would
agree that it cuts the namespace in half (much, much smaller sounds like
orders of magnitude). Still, the namespace is awfully big. Are you really
going to want to have variables x and X - or MySQL_Connect and
MySQL_connect? Can you honestly tell me that it will NOT be the cause of
errors down the road - maybe not by you, but by someone else who has to
maintain the code?
> Failing to set your development environment for development isn't failure
of
> the language. It's a failure of the programmer. The facilities are there.
> Of course, error_reporting E_ALL is a poor excuse for a debugger, but keep
> in mind that you didn't have to pay a nickel for PHP. And the you have
full
> access to it's internals, so you can always write (or hire someone to do
so)
> an IDE that will catch your typos for you.
>
> BTW, if you set error_reporting to 15 in PHP 4, you won't get almost any
> error messages - numeric value of E_ALL is 2047.
Thanks for pointing out the E_ALL constant - that is the right way to go.
Still, flagging undefined variables is only half the problem<g>.
> >To take advantage of case sensitivity to hack around something the
language
> >is missing seems like a poor reason to implement it. If there is a
> >significant enough need to have multiple constructors, then that aspect
of
> >the language should be addressed. Case sensitivity is not a nicety for
> >professional developers - it's just something that makes the
> >compiler/interpreter language parsing code easier to write.
>
> Plus easier to read, and, believe or not, for some, it's easier to write.
I think that there is a disconnect between the case-sensitive (CS) and
case-insensitive (CI)proponents. I, and I expect most other
case-insensitive advocates are not expecting or desiring to refer to the
same variable/function with different case usages. We just want it to be
treated the same in case it does get typed with a different case. I expect
that my naming conventions are similar to yours - there already exists in
the computer field some generally accepted practices that it makes sense to
follow. I also adhere to the case of pre-defined functions, constants, &
variables. Thus, I expect my code will look just like yours, so it will be
just as easy (or hard) to read or write it as yours. The only difference is
that I won't be able to have x & X refer to two different
variables/functions which is confusing & leads to bugs.
> >Making it
> >case-insensitive would help eliminate errors which I would think that all
> >developers, both professional & hobby, would welcome.
>
> No. Certainly not. I guess there's a lot of people used to VB in
php-windows@,
> and I'm not subscribed to php-general@ anymore, so I don't know about
that,
> but everyone who raised their voice on this topic on php-dev@ or php-qa@
has
> been for making function names case-sensitive.
I'm comparing it to VB only because many people are familiar with it. I've
used quite a few languages over the years, and have read & used different
coding styles & standards. The argument is not one based on VB familiarity,
but rather cross-language best practices (for the using programmers). I'd
like to hear why the folks on the other lists they want case-sensitive
functions & if the arguments are from a user perspective or a tool developer
one.
BTW: I checked the other lists you mentioned & saw your message from this
board. Thanks for letting the folks there know about some of our concerns.
-- Greg
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
