May be I misunderstood something, but why to introduce unicode escapes if
PHP engine doesn't support Unicode.
Always converting such escapes into UTF-8 encoding, doesn't make any sense
for people who use other encodings for output, databases, etc.
Thanks. Dmitry.
On Tue, Nov 25, 2014 at 1:09
On 24.11.14 23:09, Andrea Faulds wrote:
Good evening,
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
I think the choice of \u{xx} is interesting, i.e. using '{' and '}'.
Afaik, one of the current best practices is to use json_decode(), like so:
$ cat test.php
?php var_dump(
On 25 Nov 2014, at 08:33, Dmitry Stogov dmi...@zend.com wrote:
May be I misunderstood something, but why to introduce unicode escapes if PHP
engine doesn't support Unicode.
We don't have Unicode strings which are made of codepoints rather than bytes,
sure. But we do usually treat these
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 25 Nov 2014, at 08:33, Markus Fischer mar...@fischer.name wrote:
On 24.11.14 23:09, Andrea Faulds wrote:
Good evening,
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
I think the choice of \u{xx} is interesting, i.e. using '{' and '}'.
Afaik, one of the current best
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 Mon, 24 Nov 2014, Sara Golemon wrote:
On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds a...@ajf.me wrote:
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
I'm okay with producing UTF-8 even though our strings are technically
binary. As you state, UTF-8 is the de-facto encoding,
On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Nov 2014, at 08:33, Dmitry Stogov dmi...@zend.com wrote:
May be I misunderstood something, but why to introduce unicode escapes
if PHP engine doesn't support Unicode.
We don't have Unicode strings which are made of
On 25 Nov 2014, at 10:32, Derick Rethans der...@php.net wrote:
On Mon, 24 Nov 2014, Sara Golemon wrote:
On the BMP versus SMP issue of \u styles, we addressed this in
PHP6 by making \u denote 4 hexit BMP codepoints, while \U denoted six
hexit codepoints. e.g.\u1234 === \U001234
On 25 Nov 2014, at 10:41, Dmitry Stogov dmi...@zend.com wrote:
u8string tells that the whole string is UTF-8 encoded.
Your escape Unicode proposal assumes just UTF-8 codepoint, but the whole
string encoding is still undefined.
True. There’s an assumption there that you’re using a
On Tue, Nov 25, 2014 at 02:41:48PM +0400, Dmitry Stogov wrote:
I'm not completely against it. It's just an incomplete solution.
echo \u{1F602}; // won't output if the output encoding is not UTF-8
echo Привет \u{1F602}; // won't output anything useful if script
encoding is not UTF-8
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 11:20, Alain Williams a...@phcomp.co.uk wrote:
I think that we need to clarify what we are talking about.
What Andrea has proposed is a way of writing string constants. These
characters
in these strings will still be 8 bits big, this means that there needs to be
some
Ivan Enderlin @ Hoa wrote:
Le 24/11/2014 23:09, Andrea Faulds a écrit :
Good evening,
Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape
It has a rationale section explaining why certain decisions were made,
that I’d recommend you read in full.
Excellent RFC, thank you for this
On Tue, Nov 25, 2014 at 11:25:17AM +, Andrea Faulds wrote:
Well, we *do* already have a compile-time system for declaring encoding, the
declare() construct.
I missed that. Reading the documentation I confess that I do not really
understand what the effect of declare(encoding=xxx) does.
On Tue, 25 Nov 2014, Dmitry Stogov wrote:
On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Nov 2014, at 08:33, Dmitry Stogov dmi...@zend.com wrote:
May be I misunderstood something, but why to introduce unicode escapes
if PHP engine doesn't support Unicode.
Hi all,
On Tue, Nov 25, 2014 at 8:09 PM, Andrea Faulds a...@ajf.me wrote:
non-BMP code points are more important than ever.
Yes, it is! We(Japanese) have number of them already.
\u{code point} has huge advantage. We do not have care if code point value
is BMP or not.
i.e. We can do
echo
On 25 Nov 2014, at 11:48, Derick Rethans der...@php.net wrote:
I think incomplete nails it on the head. Without proper Unicode
support in the parser, compiler and string function semantics, having
these escape codes doesn't really do a lot for us.
How so? Why are they less useful because
On Tue, Nov 25, 2014 at 2:18 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Nov 2014, at 10:41, Dmitry Stogov dmi...@zend.com wrote:
u8string tells that the whole string is UTF-8 encoded.
Your escape Unicode proposal assumes just UTF-8 codepoint, but the
whole string encoding is still
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
Hi Internals!
I've submitted a PR based on Frank Denis's work in libsodium that makes
bin2hex() run in constant time () as an improvement to mitigate
cache-timing attacks. My motivation for doing so is that many developers
(including myself) use base-16 and base-64 encoding to store cryptographic
Scott Arciszewski wrote on 25/11/2014 15:37:
Hi Internals!
I've submitted a PR based on Frank Denis's work in libsodium that makes
bin2hex() run in constant time () as an improvement to mitigate
cache-timing attacks. My motivation for doing so is that many developers
(including myself) use
Dear Internals,
As you may remember, I closed the voting on the return types
[RFC](https://wiki.php.net/rfc/returntypehinting) because of a design
flaw that was found during the voting process. The purpose of this
discussion thread is to explain the various options for checking
return type
On Fri, Nov 21, 2014 at 11:20 AM, Levi Morrison le...@php.net wrote:
BTW, old constructor has problem with traits (is this mentioned already?)
http://3v4l.org/KZKXo
I suppose nobody is using this side effect in production code, but
there would be number of users who are confused by this
-Ursprüngliche Nachricht-
Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von
Levi Morrison
Gesendet: Dienstag, 25. November 2014 18:09
An: internals
Betreff: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
Dear Internals,
As you may
It should be mentioned for Option 3 that covariant return types are not
supported just at the definition level . Even with invariant return types the
following is perfectly fine:
class A {
function foo(): B { return new B; }
}
class B extends A {
function foo(): B { return new C; }
Is this crash easily/consistently reproducible? Is it an issue you think is
readily fixable? If this is the case, open a new bug.
Or is it really rare? Would it likely go unfixed/unvalidated fix for a long
time? If this is the case, you should add this to bug #68439, which is a
collection of
On Tue, Nov 25, 2014 at 3:20 AM, Alain Williams a...@phcomp.co.uk wrote:
If we decide to support non-utf-8 encoding at compile time then we could
extend
the syntax a bit to allow the encoding to be specified, eg:
\U{utf-8: arabic letter alef}
\U{iso-8859-6: arabic letter alef}
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
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
https://wiki.php.net/rfc/remove_php4_constructors
Entirely +1 on removing them in PHP7.
Did we decide on having a 5.7 release? (I was on vacation and may have
missed this) If so, then the timeline is perfect, one full release
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
https://wiki.php.net/rfc/remove_php4_constructors
Entirely +1 on removing them in PHP7.
Did we decide on having a 5.7 release? (I was on vacation and may have
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class =
Hi internals,
In OOP it's a sometimes a common issue to know the state of an object
and to know if it was changed respectively it it can change state.
We already have such objects like DateTImeImmutable and new proposed
objects like UString also introduce immutable objects.
I think it
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of
Am 25.11.2014 um 23:13 schrieb Marc Bennewitz:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2)
because
one of the use cases for return type-hint are factories
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz dev@mabe.berlin wrote:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for
37 matches
Mail list logo
