On Thu, Jul 2, 2015 at 6:43 AM, "Ivan Enderlin"@Hoa
wrote:
> Just a small detail. Please, choose another name. The `Hoa\String`
> https://packagist.org/packages/hoa/string library has been renamed to
> `Hoa\Ustring` because of PHP7. So, please, don't force us to rename the
> library again ;-).
>
A
Hi Ivan
2015-07-02 15:48 GMT+02:00 "Ivan Enderlin"@Hoa :
> I fear it will be a reserved keyword.
Internally defined classes, such as UConverter or stdClass are not
reserved keywords, they are not an actual part of the language but a
part of the library. Code like the one below is perfectly valid,
I fear it will be a reserved keyword.
On 02/07/15 15:46, Andreas Heigl wrote:
Hi.
Am 02.07.15 um 15:43 schrieb "Ivan Enderlin"@Hoa:
Hello :-),
Just a small detail. Please, choose another name. The `Hoa\String`
https://packagist.org/packages/hoa/string library has been renamed to
`Hoa\Ustring`
Hi.
Am 02.07.15 um 15:43 schrieb "Ivan Enderlin"@Hoa:
> Hello :-),
>
> Just a small detail. Please, choose another name. The `Hoa\String`
> https://packagist.org/packages/hoa/string library has been renamed to
> `Hoa\Ustring` because of PHP7. So, please, don't force us to rename the
> library aga
Hello :-),
Just a small detail. Please, choose another name. The `Hoa\String`
https://packagist.org/packages/hoa/string library has been renamed to
`Hoa\Ustring` because of PHP7. So, please, don't force us to rename the
library again ;-).
Moreover, this library provides an API that is useful
> On Jul 1, 2015, at 2:25 PM, Anatol Belski wrote:
>
>> Expanding on this idea, a separate RFC could propose a magic
> __cast($value)
>> static method that would be called for code like below:
>>
>> $obj = (ClassName) $scalarOrObject; // Invokes
>> ClassName::__cast($scalarOrObject);
>>
>> Thi
Hi,
> -Original Message-
> From: Aaron Piotrowski [mailto:aa...@icicle.io]
> Sent: Wednesday, July 1, 2015 9:00 PM
> To: Sara Golemon
> Cc: pthre...@pthreads.org; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] UString
>
>
> > On Jul 1, 2015, a
> On Jul 1, 2015, at 1:06 PM, Sara Golemon wrote:
>
> On Tue, Jun 30, 2015 at 10:36 PM, Joe Watkins wrote:
>> Another possible issue is engine integration:
>>
>>$string = (UString) $someString;
>>$string = (UString) "someString";
>>
> That sounds as a cool idea to discuss as a complet
On Tue, Jun 30, 2015 at 10:36 PM, Joe Watkins wrote:
> Another possible issue is engine integration:
>
> $string = (UString) $someString;
> $string = (UString) "someString";
>
That sounds as a cool idea to discuss as a completely separate,
unrelated RFC, and not specific to UString.
e.g.
Morning,
> Why would that be expected behaviour? I mean I can't do
>
>$date = (DateTime) $timestring;
No, but you can't do:
$string = (string) $datetime;
But can do:
$string = (string) $ustring;
Where $ustring is instanceof UString.
Even if you never write $string = (string) $us
Hi Joe.
Am 01.07.15 um 07:36 schrieb Joe Watkins:
> [..]
>
> Another possible issue is engine integration:
>
> $string = (UString) $someString;
> $string = (UString) "someString";
>
> These aren't very different to 'new UString', but for an integrated
> solution, kind of expected to wor
Morning Sara,
> Curious what the current state of the UString RFC is. I've got a
> functionality request for HHVM to wrap icu::UnicodeString and was
> hoping to match PHP behavior if any plans had been made, and lo...
> here's a plan!
I was (semi) convinced by Dmitry that the superior implementa
On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov wrote:
> On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins wrote:
>> https://wiki.php.net/rfc/ustring
>>
>> This is the result of work done by a few of us, we won't be
>> opening any
>> vote in a fortnight. We have a long time before 7, the
On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov wrote:
> On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins wrote:
>
>> Morning internalz,
>>
>> https://wiki.php.net/rfc/ustring
>>
>> This is the result of work done by a few of us, we won't be
>> opening any
>> vote in a fortnight. We hav
On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins wrote:
> Morning internalz,
>
> https://wiki.php.net/rfc/ustring
>
> This is the result of work done by a few of us, we won't be
> opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
>
>
Hi Joe and Rowan,
On Mon, Mar 2, 2015 at 7:14 AM, Yasuo Ohgaki wrote:
> Hi Joe and Rowan,
>
> On Mon, Mar 2, 2015 at 6:37 AM, Rowan Collins
> wrote:
>
>> On 01/03/2015 20:34, Lester Caine wrote:
>>
>>> On 28/02/15 06:48, Joe Watkins wrote:
>>>
This is just a quick note to announce my
Hi Joe and Rowan,
On Mon, Mar 2, 2015 at 6:37 AM, Rowan Collins
wrote:
> On 01/03/2015 20:34, Lester Caine wrote:
>
>> On 28/02/15 06:48, Joe Watkins wrote:
>>
>>> This is just a quick note to announce my intention to ready this RFC
>>> for voting next week.
>>>
>> Since there is nothing in
Hi Rowan,
On Mon, Mar 2, 2015 at 6:32 AM, Rowan Collins
wrote:
> On 01/03/2015 21:26, Yasuo Ohgaki wrote:
>
>> Although it seems current code does not have code like GMP. I'm sure
>> we'll have this before release. i.e.
>>
>> $new = $some_ustring . 'abc'; // $new is UString object
>>
>> To imple
On 01/03/2015 20:34, Lester Caine wrote:
On 28/02/15 06:48, Joe Watkins wrote:
This is just a quick note to announce my intention to ready this RFC
for voting next week.
Since there is nothing in this which needs any changes to the core then
surly it simply needs to exist in pecl until suc
On 01/03/2015 21:26, Yasuo Ohgaki wrote:
Although it seems current code does not have code like GMP. I'm sure
we'll have this before release. i.e.
$new = $some_ustring . 'abc'; // $new is UString object
To implement feature like this, it cannot be PECL.
Why not? I would have thought any exten
On 01/03/2015 20:59, Yasuo Ohgaki wrote:
However, I don't mind too much allowing any encoding stored in "Text"/
"UString" object. IIRC, Ruby does this and have not much problem.
As I understand it, Ruby's string type is actually a whole bunch of
overloaded types, each responsible for re-implem
Hi Lester,
On Mon, Mar 2, 2015 at 5:34 AM, Lester Caine wrote:
> On 28/02/15 06:48, Joe Watkins wrote:
> > This is just a quick note to announce my intention to ready this RFC
> > for voting next week.
>
> Since there is nothing in this which needs any changes to the core then
> surly it sim
Hi Florian,
On Mon, Mar 2, 2015 at 5:57 AM, Florian Margaine
wrote:
> Le 1 mars 2015 21:26, "Derick Rethans" a écrit :
> >
> > 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
> > nev
Hi Joe and Derick,
On Mon, Mar 2, 2015 at 5:25 AM, Derick Rethans wrote:
> 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
Hi,
Le 1 mars 2015 21:26, "Derick Rethans" a écrit :
>
> 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.
>
>
On Sat, 28 Feb 2015, Rowan Collins wrote:
> On 28/02/2015 06:48, Joe Watkins wrote:
> > 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, s
On 28/02/15 06:48, Joe Watkins wrote:
> This is just a quick note to announce my intention to ready this RFC
> for voting next week.
Since there is nothing in this which needs any changes to the core then
surly it simply needs to exist in pecl until such time as a proper
replacement for unicod
On Sun, 1 Mar 2015, Yasuo Ohgaki wrote:
> Hi Joe,
>
> On Sun, Mar 1, 2015 at 7:14 PM, Yasuo Ohgaki wrote:
>
> >public function __construct([string $string [, string $source_codepage
> > [, string $substitute_char] ]);
>
> One additional comment for constructor. It should have default
> no
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
int
Hi Joe,
On Sun, Mar 1, 2015 at 7:14 PM, Yasuo Ohgaki wrote:
>public function __construct([string $string [, string $source_codepage
> [, string $substitute_char] ]);
One additional comment for constructor. It should have default
normalization. I think
it should be NFC as most system uses i
Hi Joe,
On Sun, Mar 1, 2015 at 6:14 PM, Yasuo Ohgaki wrote:
> On Sat, Feb 28, 2015 at 3:48 PM, Joe Watkins
> wrote:
>
>> 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,
Hi Joe,
On Sat, Feb 28, 2015 at 3:48 PM, Joe Watkins wrote:
> 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 inten
On 28/02/2015 06:48, Joe Watkins wrote:
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 o
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
On 24 October 2014 07:03, Joe Watkins 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
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
func
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote:
> Hi!
>
> > Not ready for discussion yet ...
> >
> > https://wiki.php.net/rfc/hashkey
>
> Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
> we should combine them :)
>
Done, branch @ http://github.com/krakjoe/php-
On Thu, 2014-10-23 at 12:47 -0700, Stas Malyshev wrote:
> Hi!
>
> > Not ready for discussion yet ...
> >
> > https://wiki.php.net/rfc/hashkey
>
> Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
> we should combine them :)
>
Happy to port patch already written to confor
> On 23 Oct 2014, at 20:54, Stas Malyshev wrote:
>
>> 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.
I don't like that. This might sound crazy, but what about adding Unicode string
literals to the parser, e
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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Hi!
> Not ready for discussion yet ...
>
> https://wiki.php.net/rfc/hashkey
Hey, I've just started my own... https://wiki.php.net/rfc/objkey I guess
we should combine them :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Developme
On Thu, 2014-10-23 at 14:59 +0100, Andrea Faulds wrote:
> > On 23 Oct 2014, at 14:53, Johannes Schlüter wrote:
> >
> >> On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
> >> It doesn't solve the problem directly but allows the programmer to solve
> >> it for themselves, just like Object.hash
> On 23 Oct 2014, at 14:53, Johannes Schlüter wrote:
>
>> On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
>> It doesn't solve the problem directly but allows the programmer to solve
>> it for themselves, just like Object.hashCode in Java.
>
> The point is that it won't work in this way:
>
On Thu, 2014-10-23 at 11:38 +0100, Joe Watkins wrote:
> It doesn't solve the problem directly but allows the programmer to solve
> it for themselves, just like Object.hashCode in Java.
The point is that it won't work in this way:
$a = [ $ustring => $value ];
foreach ($a as $key => $v) {
> On 23 Oct 2014, at 14:44, Rowan Collins wrote:
>
> Dmitry Stogov wrote on 21/10/2014 10:01:
>> The "right" approach, would be extending zend_string with "encoding" and
>> then adopting near all functions working with zend_string to take
>> "encoding" into account. But, of course, this is going
Dmitry Stogov wrote on 21/10/2014 10:01:
The "right" approach, would be extending zend_string with "encoding" and
then adopting near all functions working with zend_string to take
"encoding" into account. But, of course, this is going to lead to much more
complicated solution (with some slowdown)
> On 23 Oct 2014, at 09:44, Dmitry Stogov wrote:
>
> this won't completely solve the problem, because array keys won't be
> UString anymore.
Sure, but unless we turn arrays into SplObjectStorage that won’t change. Nobody
wants to touch arrays and make them support other key types. Heck, my big
On Thu, 2014-10-23 at 12:44 +0400, Dmitry Stogov wrote:
> this won't completely solve the problem, because array keys won't be
> UString anymore.
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()
Others solve this problem in exactly this way, the Java implementation
requir
Joe Watkins wrote on 23/10/2014 09:18:
I'd rather higher level stuff existed at a higher level, I'd rather
solve for ustring the problems that are solved for normal strings and
leave the rest up to whatever the framework/component/library or wants
to do.
It's not really higher level in terms of
this won't completely solve the problem, because array keys won't be
UString anymore.
Thanks. Dmtiry.
On Thu, Oct 23, 2014 at 12:11 PM, Joe Watkins wrote:
> On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote:
> > Hi!
> >
> > > I wish there was a way for specific objects to opt into this.
>
On Tue, 2014-10-21 at 07:49 -0700, Sara Golemon wrote:
> > On Oct 21, 2014, at 0:06, Joe Watkins wrote:
> >
> > Morning internalz,
> >
> >https://wiki.php.net/rfc/ustring
> >
> >This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a lo
On Tue, 2014-10-21 at 10:28 -0700, Stas Malyshev wrote:
> Hi!
>
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a long time before 7, there is no rush
> > whatever.
>
> Couple of thought
On Tue, 2014-10-21 at 21:42 +0100, Rowan Collins wrote:
> On 21/10/2014 08:06, Joe Watkins wrote:
> > Morning internalz,
> >
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be opening any
> > vote in a fortnight. We have a long time befo
On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote:
> Hi!
>
> > I wish there was a way for specific objects to opt into this.
>
> There will be, if __hashKey() or whatever would be the properly
> bikeshedded name, becomes reality as discussed elsewhere. It shouldn't
> be hard to do and it's e
hi,
On Tue, Oct 21, 2014 at 4:01 PM, Dmitry Stogov wrote:
> Hi Joe,
>
> As an extension it looks fine.
> I assume, you don't propose to use UString objects in engine and other
> extensions.
> Unfortunately, it's yet another incomplete solution.
I have to agree here.
As much as I like what has b
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds wrote:
>Make array-like indexing with [] be by
>code points as you may be able to do that in constant time
If the internal representation is UTF8, both code point and grapheme access
require traversal unless you have some additional index s
On 21 October 2014 23:21:37 GMT+01:00, Andrea Faulds wrote:
>
>> On 21 Oct 2014, at 21:42, Rowan Collins
>wrote:
>>
>> The only case I can see where a default encoding would be sensible
>would be where source code itself is in a different encoding, so that
>u('literal string') works as expected.
> On 21 Oct 2014, at 21:42, Rowan Collins wrote:
>
> The only case I can see where a default encoding would be sensible would be
> where source code itself is in a different encoding, so that u('literal
> string') works as expected.
This is only a good idea if we can somehow make it file-loca
On 21/10/2014 08:06, Joe Watkins wrote:
Morning internalz,
https://wiki.php.net/rfc/ustring
This is the result of work done by a few of us, we won't be opening any
vote in a fortnight. We have a long time before 7, there is no rush
whatever.
Now seems like a good time t
Hi!
> Just a quick point: most of the core is not ASCII. PHP strings are byte
> strings, completely divorced from any encoding. A few native functions
> assume ISO8859-1 (or possibly Windows CP1252), but mostly they just
> juggle which ever bytes you give them.
True, but not all extensions and
Hi!
> I wish there was a way for specific objects to opt into this.
There will be, if __hashKey() or whatever would be the properly
bikeshedded name, becomes reality as discussed elsewhere. It shouldn't
be hard to do and it's exactly what many other languages do when trying
to use objects as keys
Hi!
> https://wiki.php.net/rfc/ustring
>
> This is the result of work done by a few of us, we won't be opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
Couple of thoughts:
- I like the idea of having a unicode string class. May be a way to
> On Oct 21, 2014, at 0:06, Joe Watkins wrote:
>
> Morning internalz,
>
>https://wiki.php.net/rfc/ustring
>
>This is the result of work done by a few of us, we won't be opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
>
The backend abstrac
On 21/10/2014 15:17, Lester Caine wrote:
> On 21/10/14 11:50, Matteo Beccati wrote:
>> However, doesn't ICU use UTF-16 by default which is undesirable as most
>> of the times it requires converting from and to UTF-8?
>
> http:// userguide.icu-project.org/strings/utf-8
> It is interesting that the
So, one thing which I think is worth bringing up is code points vs.
characters/graphemes.
This came up in another recent thread about Unicode on internals. While
code-point manipulation is all well and good, we also need grapheme
manipulation functions. Could we add these? That would make the A
> On 21 Oct 2014, at 13:35, Christian Schneider wrote:
>
> I have one concern I want to bring up: The RFC proposes a helper function u()
> to generate UStrings.
>
> As this is a very handy function name for all sort of utility functions (as a
> matter of face we use it to create and sanitize
On 21 October 2014 14:35, Christian Schneider wrote:
> Am 21.10.2014 um 09:06 schrieb Joe Watkins :
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be
> opening any
> > vote in a fortnight. We have a long time before 7, there is no
Am 21.10.2014 um 09:06 schrieb Joe Watkins :
> https://wiki.php.net/rfc/ustring
>
> This is the result of work done by a few of us, we won't be opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
I have one concern I want to bring up: The RFC
On 21/10/14 12:11, Rowan Collins wrote:
> Lester Caine wrote (on 21/10/2014):
>> If we are going down the root of keeping PHP7 as ascii only in the core,
>> then ustring probably makes sense, but it does not address many of the
>> areas where unicode is really needed.
>
> Just a quick point: most
Lester Caine wrote (on 21/10/2014):
If we are going down the root of keeping PHP7 as ascii only in the core,
then ustring probably makes sense, but it does not address many of the
areas where unicode is really needed.
Just a quick point: most of the core is not ASCII. PHP strings are byte
stri
On 21/10/2014 09:06, Joe Watkins wrote:
> Morning internalz,
>
> https://wiki.php.net/rfc/ustring
>
> This is the result of work done by a few of us, we won't be opening any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
>
> Now seems like a g
On 21/10/14 10:52, Dmitry Stogov wrote:
>> That seems a lot like bashing our head against a wall. We tried to
>> > introduce support everywhere and it fails. Do we really want to step on
>> > the performance gains introduced by recent changes by making all strings
>> > unicode ?
>> >
> Yeah :)
> I'
On Tue, 2014-10-21 at 13:52 +0400, Dmitry Stogov wrote:
>
>
> On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins
> wrote:
> On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote:
> > Hi Joe,
> >
> >
> > As an extension it looks fine.
> >
> > I a
#x27;t find anything in the RFC about it but maybe you
> thought that is implicit given).
>
> Cheers,
> Robert
>
> > -Ursprüngliche Nachricht-
> > Von: Joe Watkins [mailto:pthre...@pthreads.org]
> > Gesendet: Dienstag, 21. Oktober 2014 09:07
> > An
On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins wrote:
> On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote:
> > Hi Joe,
> >
> >
> > As an extension it looks fine.
> >
> > I assume, you don't propose to use UString objects in engine and other
> > extensions.
>
> I'm not proposing it now, no.
>
>
given).
Cheers,
Robert
> -Ursprüngliche Nachricht-
> Von: Joe Watkins [mailto:pthre...@pthreads.org]
> Gesendet: Dienstag, 21. Oktober 2014 09:07
> An: internals@lists.php.net
> Betreff: [PHP-DEV] [RFC] UString
>
> Morning internalz,
>
> https://wiki.php.net/rf
On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote:
> Hi Joe,
>
>
> As an extension it looks fine.
>
> I assume, you don't propose to use UString objects in engine and other
> extensions.
I'm not proposing it now, no.
> Unfortunately, it's yet another incomplete solution.
>
> It won't all
Hi,
@Philip: please read the discussion that happened a month ago (and follow
up on it if necessary):
http://marc.info/?l=php-internals&m=141145952422734&w=2
Regards,
On Tue, Oct 21, 2014 at 11:19 AM, Philip Hofstetter <
phofstet...@sensational.ch> wrote:
> Hello
>
> Tangentially related:
>
> O
Hello
Tangentially related:
On Tuesday, October 21, 2014, Dmitry Stogov wrote:
>
>
> It won't allow Unicode strings as array keys;
I wish there was a way for specific objects to opt into this.
Using __toString() we have something that mostly behaves just like a
string and can be used whereve
On 21 October 2014 09:01, Joe Watkins wrote:
>
> ZEND_CONCAT is overloaded, as well as read_dimension and cast (to
> string) handlers. This seems to cover everything, unless I missed
> something ?
>
ZEND_CONCAT and ZEND_ASSIGN_CONCAT were my primary concerns, I didn't
see any mention of these in
Hi Joe,
As an extension it looks fine.
I assume, you don't propose to use UString objects in engine and other
extensions.
Unfortunately, it's yet another incomplete solution.
It won't allow Unicode strings as array keys;
concatenation using "." (probably may be done),
no auto-conversion from/to s
This is great thanks for the work!
I think we should have an opinion on grapheme clusters and tell about it in
the RFC.
I do support the idea that PHP users need to handle "characters" in term of
"graphemes". We need a core way to deal with code points of course, but
things like "reverse" have ver
On Tue, 2014-10-21 at 09:02 +0100, Lester Caine wrote:
> On 21/10/14 08:06, Joe Watkins wrote:
> > Now seems like a good time to start the conversation so we can hash out
> > the details, or get on with other things ;)
>
> Does this address the problem of sorting array keys using a particular
> la
On 21/10/14 08:06, Joe Watkins wrote:
> Now seems like a good time to start the conversation so we can hash out
> the details, or get on with other things ;)
Does this address the problem of sorting array keys using a particular
language or collation?
--
Lester Caine - G8HFL
On Tue, 2014-10-21 at 08:40 +0100, Leigh wrote:
> On 21 October 2014 08:06, Joe Watkins wrote:
> > Morning internalz,
> >
> > https://wiki.php.net/rfc/ustring
> >
> > This is the result of work done by a few of us, we won't be opening
> > any
> > vote in a fortnight. We have a lon
> -Original Message-
> From: Joe Watkins [mailto:pthre...@pthreads.org]
> Sent: Tuesday, October 21, 2014 10:07 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC] UString
>
> Morning internalz,
>
> https://wiki.php.net/rfc/ustring
>
> T
On 21 October 2014 08:06, Joe Watkins wrote:
> Morning internalz,
>
> https://wiki.php.net/rfc/ustring
>
> This is the result of work done by a few of us, we won't be opening
> any
> vote in a fortnight. We have a long time before 7, there is no rush
> whatever.
>
> Now se
Morning internalz,
https://wiki.php.net/rfc/ustring
This is the result of work done by a few of us, we won't be opening any
vote in a fortnight. We have a long time before 7, there is no rush
whatever.
Now seems like a good time to start the conversation so we can hash ou
88 matches
Mail list logo
