> On 28 Nov 2014, at 06:49, Stanislav Malyshev wrote:
>
>> If we add that, we should also have an analogue of JavaScript’s
>> String.charCodeAt/String.codePointAt to do the operation in reverse.
>
> That'd be a bit harder since it's not clear what "at" means there -
> byte? codepoint? grapheme
On Thu, Nov 27, 2014 at 12:22 AM, Stanislav Malyshev
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 built-in wa
On 28 November 2014 06:51:56 GMT, Stanislav Malyshev
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 to MDN, the
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!
> 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
Andrea Faulds wrote on 27/11/2014 13:48:
On 27 Nov 2014, at 08:22, Stanislav Malyshev 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) d
> On 27 Nov 2014, at 08:22, Stanislav Malyshev 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 built-in way
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/int
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.cha
On Tue, Nov 25, 2014 at 5:14 AM, Andrea Faulds 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 initial R
> On 25 Nov 2014, at 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 in
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 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).
>
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).
>
>
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 Intern
15 matches
Mail list logo
