Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.161.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=CX8PAE/3/KTEhZKjFyp/biW59t7jJG7JuXjViQPYz3E/LMEfIulabi6rLg/EF2QwSo
         NmCSUMh0mQIFu7IM3sak2I4wz5K9oP+RaOSpV9E4re9QaMVzvWmb9pTKsLB9bxBIipye
         ABfoOjSUdDmZK9tpTjEx50lysHIK8/XAcPJwo=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <j2ze50d0a481005050416td7c313efx3c69fccf9ebba1bb@mail.gmail.com>
References: <r2se50d0a481004182058i1ca96f6ka9f7a4e545c98e5e@mail.gmail.com> 
	<p2ie50d0a481005040514h8720228qe2ae6a589deab4ab@mail.gmail.com> 
	<m2k7f3ed2c31005050125i41eea9d9rc9cc5b1ea1c4ba70@mail.gmail.com> 
	<4BE13D64.2010700@gmail.com> <p2h7f3ed2c31005050323qd733ad0awd46e1ff8e1162276@mail.gmail.com> 
	<4BE14FFE.4010501@gmail.com> <j2ze50d0a481005050416td7c313efx3c69fccf9ebba1bb@mail.gmail.com>
Date: Wed, 5 May 2010 13:19:13 +0100
Message-ID: <i2m10845a341005050519mc15d3005of67990a79b65ceb2@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Steven Van Poeck <svanpoeck@gmail.com>, Hannes Magnusson <hannes.magnusson@gmail.com>, 
	internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Turkish/Azeri locale support
From: rquadling@googlemail.com (Richard Quadling)

On 5 May 2010 12:16, Adam Harvey <aharvey@php.net> wrote:
> On 5 May 2010 19:01, Steven Van Poeck <svanpoeck@gmail.com> wrote:
>> Right. That's what I meant by inconsistent code. The call
>> $logs->getSQLLogger()->logSql("...") would function I presume.
>> The reason your example code does not is because it is inconsistent. You=
're
>> calling $logs->getSqlLogger() instead of $logs->getSQLLogger()
>
> Agreed, but not everyone's going to spot that first time, particularly
> the sorts of newer programmers we get quite a lot of writing PHP.
> Also, the error message you get out the other end is suboptimal, to
> say the least.
>
> I've been holding out on stating my reasoning much beyond my initial
> post and vote to try avoiding influencing anyone, but I'm opinionated,
> so here goes. :)
>
> Here's an example of my problem with enforcing case-sensitivity in
> general that builds on something Johannes said yesterday on IRC: how
> many people use different cases for the gd functions? Taking, say,
> imagestring as a simple example and having a quick look at Google Code
> Search, the variants people are using there are:
>
> ImageString: about 3000 results [0]
> imagestring: about 4000 results [1]
> imageString: 453 results [2]
> IMAGESTRING: 1 result [3]
>
> There are probably other variations in use too, and that's one of the
> more simply named functions in gd.
>
> The above example pretty much sums up why I went for option 1 instead
> of 2 in my vote: it's still a BC break, but I honestly thing it's
> going to be a much more minor break (remember, it only affects people
> in certain Western European locales such as French, Spanish and German
> who are _also_ using single-byte encodings =E2=80=94 most Linux distros I=
 know
> of are shipping with UTF-8 as a default, so they're already
> effectively case-sensitive for non-ASCII characters) than changing the
> entire language and probably causing issues in a wide variety of
> applications.
>
> If I was designing the language anew, sure, I'd go for
> case-sensitivity the whole way, but as things stand, I'm pretty
> dubious it would work out.
>
> Adam
>
> [0] http://www.google.com.au/codesearch?as_q=3D%22ImageString%22&btnG=3DS=
earch+Code&hl=3Den&as_lang=3Dphp&as_license_restrict=3Di&as_license=3D&as_p=
ackage=3D&as_filename=3D&as_case=3Dy
> [1] http://www.google.com.au/codesearch?as_q=3Dimagestring&btnG=3DSearch+=
Code&hl=3Den&as_lang=3Dphp&as_license_restrict=3Di&as_license=3D&as_package=
=3D&as_filename=3D&as_case=3Dy
> [2] http://www.google.com.au/codesearch?as_q=3DimageString&btnG=3DSearch+=
Code&hl=3Den&as_lang=3Dphp&as_license_restrict=3Di&as_license=3D&as_package=
=3D&as_filename=3D&as_case=3Dy
> [3] http://www.google.com.au/codesearch?as_q=3DIMAGESTRING&btnG=3DSearch+=
Code&hl=3Den&as_lang=3Dphp&as_license_restrict=3Di&as_license=3D&as_package=
=3D&as_filename=3D&as_case=3Dy
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

_IF_ case sensitivity is going to be incorporated and the BC is too
great, is the following an option.

1 - Introduce case sensitivity with an option to allow a fallback to
the existing mechanism.
2 - Generate an E_NOTICE or an E_STRICT to inform developers/users of the i=
ssue.
3 - Stick with the fallback for a while until it is removed
(introduced in 5.x then drop in 7.x).

Alternatively, only activate case sensitivity if E_STRICT is set. If a
developer is creating E_STRICT code, I doubt that they are sloppy with
their case.



E_STRICT is documented as "Enable to have PHP suggest changes to your
code which will ensure the best interoperability and forward
compatibility of your code.". Which seems a perfect fit.

--=20
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling