Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100558
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3D.0C.10715.383F8B95@pb1.pair.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com>
 <3D.0C.10715.383F8B95@pb1.pair.com>
Date: Wed, 13 Sep 2017 07:15:43 -0600
Message-ID: <CAObuZdtmhxQ285hwMc3x9TH2rj9D7Ty3vnhNPcBzdCePpch9YA@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11352d32070d33055911f5f4"
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: derokorian@gmail.com (Ryan Pallas)

--001a11352d32070d33055911f5f4
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com>
wrote:

>
>>
> You seem to forget that autoloading is an option, not a requirement. I
> don't use autoloading in my 14 year old framework for several reasons:
> - An autoloader did not exist when I created my framework.
> - I built an alternative mechanism into my framework, so I don't need an
> autoloader.
> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>

I must be missing something, there is no autoloader shipped with PHP. You
have to define your own and register it. You can choose to change _ into /
within your autoloader, but that is entirely preference and not
specifically part of autoloading. For example, here's my autoloader which
does no such symbol replacement https://pastebin.com/rQRrXzCa


>
> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
> However, I would be totally against switching the rest of the language to
> be case sensitive for the following reasons:
> - It would be a huge BC break no little or no benefit.
> - It would allow developers to shoot themselves in the foot by having
> different functions with the same name but different mixtures of case, so
> that foo(), Foo() FOO() and fOO() would be treated as different functions.
> - if people move from keyboard input to speech recognition, then simply
> speaking a name would not work - you would have to spell it out character
> by character, and specify either upper or lowercase for each character.
>

This is about deprecating the third parameter in define, so userland
constants defined by this function cannot be case insensitive. As mentioned
before by Christoph this is not an attempt to change case sensitivity for
other identifiers (functions, classes, etc) even if it was brought up
before. That is not his intention here, and we need to stick to the focus
of this RFC.


> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed
> by people who did not understand the ramifications of their choice.
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11352d32070d33055911f5f4--