Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.213.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1503012002140.5941@whisky.home.derickrethans.nl>
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>
	<CAL=_i_nDz0XoVA5d4gqinYg9GinJUMW55+HLQ4y9O3Nj_URoxw@mail.gmail.com>
	<alpine.DEB.2.11.1503012002140.5941@whisky.home.derickrethans.nl>
Date: Sun, 1 Mar 2015 21:57:09 +0100
Message-ID: <CABRjmp9z3V5BnTuTekAQQo3fo=Z8WqdfW+b37tPFBrgxbnzarw@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Internals <internals@lists.php.net>, Joe Watkins <pthreads@pthreads.org>
Content-Type: multipart/alternative; boundary=bcaec5171e816501510510405828
Subject: Re: [PHP-DEV] [RFC] UString
From: florian@margaine.com (Florian Margaine)

--bcaec5171e816501510510405828
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Le 1 mars 2015 21:26, "Derick Rethans" <derick@php.net> a =C3=A9crit :
>
> Hey Joe,
>
> I think there are a few issues with the proposal, although I like the
> general idea. I've had the tab with the RFC open since October... but
> never looked at it until now :-/. So, a few comments:
>
> - UString as a name.
>
> I think I am going to prefer "Text" as a class name. Unicode (and
> intl/icu) have lots of operators acting on items containing unicode
> strings. But they are really pieces of text. For example sentences, word
> break iterators, etc. UString *feels* clunky, and not "standard". If
> it's going to be part of PHP core, then we should pick a "core" name. (I
> might prefer String, but that's going to cause a whole lot of issues
> obviously).

Isn't this "solved" if we use \php\String?

>
> - "Needs More Methods"
>
> I had a look at the API that that links to, and I miss operators like
> iterators. Over words, sentences, characters, etc. Basically the
> functionality of
> http://docs.php.net/manual/en/class.intlbreakiterator.php,
> http://docs.php.net/manual/en/class.intlrulebasedbreakiterator.php and
> http://docs.php.net/manual/en/class.intlcodepointbreakiterator.php
>
> I realize intl already immplements, this, but it's really beneficial to
> have for a "Text" class - especially for replacing functionality where
> people now look over a string - with a character index.
>
> - "Not a full String API Replacement"
>
> I would certainly expect more from it than just the UnicodeString API.
> Perhaps not for a first iteration, but certainly for subsequent
> versions. Things like transliterations, and specifically iterators would
> be high on my list.
>
> - "Patch"
>
> toUpper/toLower, there is a missing one for toTitle
>
> - In the code's README:
>
> "Note: UString is interchangable with zend strings for method parameters
> and can be cast for output/conversion to zend strings"
>
> How does that work? And what would it convert to?
>
> - How are "characters" counted?
>
> Is a character a Code Point, or is a character a base character +
> combining diacritics. In the first form, A + =C2=B0 is considered as
> characters, in the second option, just one. For wordwrap, splice,
> substring, it is really important that only the *full sequence* is
> considered as a character. And hence, a character really should be the
> full sequence. The text in "charAt" seems to contradict that, and that
> is a mistake.
>
> In the original PHP 6 we didn't do that due to perormance reasons, but
> that point is moot now as only people who opt into using "Text" will
> suffer from this.
>
> - "trim"
>
> What is a leading or trailing space? Is it just U+0020, or other Unicode
> defined space characters as well? (&nbsp;, U+00A0 comes to mind here)
>
> - What is "UG(defaultpad)," about?
>
> - For the code:
>
>   - there is some interesting, non standard whitespaceing going on:
>
>     - { goes on next line after a func decl
>     - sometimes 4 spaces in stead of a tab are used for indentation,
>
> - Why is there no __toString() ?
>
> - How can other extensions, not really making use of "Text", use there
>   strings (as UTF8 strings f.e.)
>
>
> cheers,
> Derick
>
>
> On Sat, 28 Feb 2015, Joe Watkins wrote:
>
> > Morning internals,
> >
> >     This is just a quick note to announce my intention to ready this RF=
C
> > 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 som=
e
> > >> 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 =3D u"unicod=
e
> > > string" since we already have $foo =3D 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=3Dfunction+u+lang%3Aphp
> > > [2]
> > >
https://github.com/facebook/hhvm/blob/master/hphp/test/slow/ext_icu/uspoof.=
php#L13
> > >
> >
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Cheers,
Florian Margaine

--bcaec5171e816501510510405828--