Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 66.111.4.27 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <5452C7D3.2060506@lsces.co.uk>
Date: Thu, 30 Oct 2014 18:30:32 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <27BEFFC5-A51E-4DDE-B982-B085A52193F2@php.net>
References: <544DA1CD.9070109@php.net> <CAEbg-4YmUzuAEJZOqqCC=vJ=XY5b7HCZnj25B_JYxu1XJof_YQ@mail.gmail.com> <4ED7146272E04A47B986ED49E771E347BD7E35E061@Ikarus.ameusgmbh.intern> <51CF9ADE-2E04-4BC0-9E5C-B93498251F59@php.net> <5452158A.6070003@lsces.co.uk> <2BB0BBCF-87D2-4E13-9B59-B18A17572B37@gmail.com> <54526AE0.7060702@lsces.co.uk> <5452786E.7020503@gmail.com> <5452C7D3.2060506@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: willfitch@php.net (Will Fitch)


> On Oct 30, 2014, at 6:20 PM, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> On 30/10/14 17:42, Rowan Collins wrote:
>> The use case which came up recently was UString objects, which can
>> easily be converted to and from plain PHP strings, but would be =
useful
>> as keys in their own right. With current PHP you could do $foo[
>> (string)$u_str ] =3D $bar; with the proposed RFC, you could do $foo[
>> $u_str ] =3D $bar with the same result; but either way, you would =
still
>> need to convert *back* to an object in order to use any of the =
UString
>> methods in a foreach(), array_walk(), etc.
>=20
> I would still like to see the debate on proper use of unicode IN PHP
> strings. Pushing that problem into objects is just as wrong as this
> debate. If I'm using a unicode colation to sort a set of array keys =
then
> the KEY should be unicode, not yet another handle to a secondary =
object
> which the needs to be sorted ... but then perhaps we need this fiddle =
to
> avoid the complexity that unicode can create?

I agree it=E2=80=99s high time Unicode be in PHP, but we are calling =
this PHP 7 and not 6 for a reason. The lessons learned in the =
difficulties of implementing Unicode directly in the language were a =
direct player in the death of PHP 6.  We need to keep that in mind as =
we=E2=80=99re continuing these types of discussions.

The only time I see this being an issue related to Unicode (short-term) =
is if we do not implement a language-integrated collation option.  For =
example, if the solution for collation in general is to use a built-in =
class or similar function, we will run into these issues. =20

However, if the assumption is we will allow collations to be =
configurable - or assume Unicode in some fashion, the weight of this =
effort will be on the implementation of Unicode and not so much this.

As it stands right now, the RFC wiki seems to have no references to =
Unicode implementation beyond 2010=E2=80=99s end of PHP6.=20

>=20
> --=20
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20