On Thu, Nov 27, 2014 at 12:22 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
Looking into this and also reading the \u{} proposal, I also thought -
do we have a programmatic way of doing what \u would do? I.e. if we
assume $x holds an Unicode codepoint value (i.e., an integer) do we have
a
On 28 November 2014 06:51:56 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
We already have the single-byte versions: chr() and ord(). It's been
on
Not really. chr(0xA1) is a byte with value 0xA1. The function I propose
would instead produce \xC2\xA1.
Ah, yes, so it would. According
Hi!
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
https://wiki.php.net/rfc/intl.char
On 27 Nov 2014, at 08:22, Stanislav Malyshev smalys...@gmail.com wrote:
Looking into this and also reading the \u{} proposal, I also thought -
do we have a programmatic way of doing what \u would do? I.e. if we
assume $x holds an Unicode codepoint value (i.e., an integer) do we have
a good
Andrea Faulds wrote on 27/11/2014 13:48:
On 27 Nov 2014, at 08:22, Stanislav Malyshev smalys...@gmail.com wrote:
Looking into this and also reading the \u{} proposal, I also thought -
do we have a programmatic way of doing what \u would do? I.e. if we
assume $x holds an Unicode codepoint value
Hi!
You mean something along the lines of JavaScript’s
String.fromCharCode (or, in ES6, String.fromCodePoint)?
Yes, exactly.
One of the nice things about that function is that it can take
multiple codes. So I can do String.fromCodePoint(65, 66, 67) to get
“ABC”.
Well, that is nice but if
Hi!
We already have the single-byte versions: chr() and ord(). It's been on
Not really. chr(0xA1) is a byte with value 0xA1. The function I propose
would instead produce \xC2\xA1.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
https://wiki.php.net/rfc/intl.char
On 25/11/14 04:47, Sara Golemon wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
On Mon, 24 Nov 2014, Sara Golemon wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
Lester Caine wrote on 25/11/2014 10:00:
On 25/11/14 04:47, Sara Golemon wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with
On 25 Nov 2014, at 04:47, Sara Golemon poll...@php.net wrote:
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching
On Tue, Nov 25, 2014 at 5:14 AM, Andrea Faulds a...@ajf.me wrote:
Is there really a need to have both an “OOP” and “non-OOP” interface here? If
it’s all static methods, why not just make it functions?
No, there isn't, but everything else in ext/intl has this duality, so
I'm offering it in the
While playing around with Andrea's unicode literals syntax proposal, I
was reminded of just how little of ICU is exposed. I've put up a
short proposal for adding IntlChar exporting these APIs as static
methods (with a matching non-oop interface).
https://wiki.php.net/rfc/intl.char
--
PHP
14 matches
Mail list logo
