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 <daveran...@php.net> wrote:
> On 24 October 2014 07:03, Joe Watkins <pthre...@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
>
