Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.220.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGAGxbaKK4P2D5epQTzEzNx3jcBP7XCPexGA4gyA3hdx3p+UKg@mail.gmail.com>
References: <1413875212.2624.3.camel@localhost.localdomain>
	<CA+9eiLtVUsbRQA9S0eagVfOc3aovhuak=QQmnBKp_BmgN4n28w@mail.gmail.com>
	<CAGKNXQEYquY_YQvTRv7uAhaycyCNG1FRwX_GYZ1dnHfhC-biZg@mail.gmail.com>
	<54469840.3070708@sugarcrm.com>
	<1414051917.2624.35.camel@localhost.localdomain>
	<CA+9eiLsC1dD9vp=uWqdYTXj7hC=mBnOMSs5B6KFngOQPd1m4OA@mail.gmail.com>
	<1414060726.2624.60.camel@localhost.localdomain>
	<1414072403.3228.3.camel@kuechenschabe>
	<87D717D5-273B-4A32-A3E5-83EBDFD314CB@ajf.me>
	<1414077690.3228.12.camel@kuechenschabe>
	<54495CF6.30608@sugarcrm.com>
	<1414130585.2624.64.camel@localhost.localdomain>
	<CAGAGxbaKK4P2D5epQTzEzNx3jcBP7XCPexGA4gyA3hdx3p+UKg@mail.gmail.com>
Date: Sat, 28 Feb 2015 06:48:10 +0000
Message-ID: <CAL=_i_nDz0XoVA5d4gqinYg9GinJUMW55+HLQ4y9O3Nj_URoxw@mail.gmail.com>
To: Chris Wright <daverandom@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Andrea Faulds <ajf@ajf.me>, Dmitry Stogov <dmitry@zend.com>, 
	Philip Hofstetter <phofstetter@sensational.ch>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6787104bf9c60510205e1c
Subject: Re: [PHP-DEV] [RFC] UString
From: pthreads@pthreads.org (Joe Watkins)

--047d7b6787104bf9c60510205e1c
Content-Type: text/plain; charset=UTF-8

Morning internals,

    This is just a quick note to announce my intention to ready this RFC
for voting next week.

    I know I'm a little late maybe, I was real sick most of last week, so
couldn't do anything useful.

    A couple of us intend to fix outstanding issues on github and those
raised here, tidy the RFC and open the vote for 7.

   I would ask anyone interested to scan through this thread and announce
concerns that are not mentioned asap.

Cheers
Joe

On Fri, Oct 24, 2014 at 3:01 PM, Chris Wright <daverandom@php.net> wrote:

> On 24 October 2014 07:03, Joe Watkins <pthreads@pthreads.org> wrote:
>
>> On Thu, 2014-10-23 at 12:54 -0700, Stas Malyshev wrote:
>> > Hi!
>> >
>> > > P.S. u() is a bad name, will break lots of code, i.e.
>> >
>> > Maybe __u()? It's a bit ugly but you're not allowed to use __ so it's
>> safe.
>> >
>>
>> /me cringes ...
>>
>> I wonder how much of a problem it really is, usually when we say some
>> function name is a problem is because of hundreds and hundreds of
>> results on github.
>>
>> If it's a huge problem then we should rename it, if we have to dig
>> around for a single project that's incompatible, or even a handful, then
>> it's not really a problem.
>>
>> Cheers
>> Joe
>
>
> I can see this being something relatively common. While I personally would
> never do it, there are a few reasons I can think of that people *might* do
> it:
>
> - Wrapper for creating <u> HTML output
> - urlencode() shortcut
> - (obviously) various unicode-related things
>
> Searching on codesearch [1] revealed (amongst a few other hits on the
> first page) another interesting use of it in the hhvm test suite [2]. It's
> difficult to search for this because all the available public search
> engines that I know of do fuzzy matching.
>
> Sorry. This sucks, because every other option we have for this is sucks.
>
> On the bright side, anything chosen could always be aliased at the top of
> the file:
>
> use function __u as u;
>
> This also sucks, but it sucks a little bit less because the collisions are
> avoided - or at least, avoided in such a way that the onus is on the user -
> and one can still have the sane name.
>
> First-class support at the syntax level (presumably $foo = u"unicode
> string" since we already have $foo = b"binary string") would IMO be better
> and (hopefully?) a long-term goal, but I am aware that it is - and probably
> should be - outside the scope of the current proposal.
>
> [1] https://searchcode.com/?q=function+u+lang%3Aphp
> [2]
> https://github.com/facebook/hhvm/blob/master/hphp/test/slow/ext_icu/uspoof.php#L13
>

--047d7b6787104bf9c60510205e1c--