> On 21 Oct 2014, at 22:01, Rowan Collins wrote:
>
> On 21/10/2014 02:17, Andrea Faulds wrote:
>> There isn’t a lack of a value, there’s no value.
>
> You might want to consider re-wording that. It comes across as rather an
> oxymoron…
Oh dear, I repeated myself accidentally. I think I meant
> On 21 Oct 2014, at 10:14, Dmitry Stogov wrote:
>
> some notes:
> - it's probably make sense to implement these function as a new opcode(s) in
> VM
That could be an optimisation later, yes. I note that you’ve added function
replacement with opcodes for certain commonly-used functions. We cou
> 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 02:17, Andrea Faulds wrote:
There isn’t a lack of a value, there’s no value.
You might want to consider re-wording that. It comes across as rather an
oxymoron...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
On 21/10/2014 02:48, Stas Malyshev wrote:
It would be possible to make to_int() merely an alias of
>filter_var(…, FILTER_VALIDATE_INT). Though that would make it depend
>on ext/filter or otherwise duplicate functionality.
You seem to sound like depending on something already existing in PHP is
a
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
On Oct 20, 2014, at 6:17 PM, Andrea Faulds wrote:
>> On 21 Oct 2014, at 02:07, Josh Watzman wrote:
>>
>> Throwing an exception or even returning NULL seems so much better than
>> returning "false" -- "false" is a boolean, not an error, and despite some
>> historical cases of PHP using "false"
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 Mon, 20 Oct 2014, Andrea Faulds wrote:
> Good evening,
>
> I am presenting a new RFC to add a set of three functions to do validated
> casts for scalar types:
>
> https://wiki.php.net/rfc/safe_cast
>
> Please read it.
> > The functions return FALSE on failure instead of NULL because:
> > -
Hello, internals!
> Good evening,
>
> I am presenting a new RFC to add a set of three functions to do validated
> casts for scalar types:
>
> https://wiki.php.net/rfc/safe_cast
>
> Please read it.
Personally I don't like this RFC because it's introducing one more way
to cast value in PHP. We alr
> 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 Oct 2014, at 09:35, Dmitry Stogov wrote:
>
> Hi Andrea,
>
> Why don't you use the ability of operator overloading? (it's in the engine
> since 5.6).
I've already answered this in this thread, but I'll answer it again if I must.
>
> BIGINT don't have to be completely transparent. If
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
On Tue, 2014-10-21 at 11:48 +0200, Robert Stoll wrote:
> Hi Joe,
>
> I have not devoted myself to unicode and thus cannot give you a feedback on
> your implementation.
> Nevertheless, I was wondering whether string interpolation is still supported
> by your solution (couldn't find anything in th
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.
>
>
Hi Joe,
I have not devoted myself to unicode and thus cannot give you a feedback on
your implementation.
Nevertheless, I was wondering whether string interpolation is still supported
by your solution (couldn't find anything in the RFC about it but maybe you
thought that is implicit given).
Che
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
Both, the idea and implementation look fine.
Personally, I hate the existing type conversion rules, and I would like to
use something like this by default (may be with exception for
null/false/true handling), but it may be a big compatibility break, so
introducing to_int() is better than nothing.
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
Hi Andrea,
Why don't you use the ability of operator overloading? (it's in the engine
since 5.6).
BIGINT don't have to be completely transparent. If user would like to work
with BIGINT, let them crate PHP objects explicitly and then use operator
overloading. e.g.
Your solution would allows wri
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
On 21/10/14 02:17, Andrea Faulds wrote:
> JavaScript returns NaN here and C sets errno to an error value. PHP uses
> FALSE, in some respects, like JavaScript uses NaN.
Isn't part of the problem here that we DO need more than a single return
in many places. Even 'bool' can be thought off as three
> -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
>
> This is the result of work done by
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
42 matches
Mail list logo
