On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
> Am 25.11.2014 um 22:43 schrieb Levi Morrison:
>
> On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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
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 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
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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 {
> public static
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 would
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 = 'MyN
On 25 November 2014 at 10:36, Sara Golemon wrote:
> On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison 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
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison 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 to
deprecate,
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 Tue, Nov 25, 2014 at 3:20 AM, Alain Williams 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}
>
God, that's s
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 har
> 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 n
> -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
On Fri, Nov 21, 2014 at 11:20 AM, Levi Morrison 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 behavi
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 compati
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 base-
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
> 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
On Tue, Nov 25, 2014 at 2:18 PM, Andrea Faulds wrote:
>
> > On 25 Nov 2014, at 10:41, Dmitry Stogov wrote:
> >
> > u8"string" 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
> On 25 Nov 2014, at 11:48, Derick Rethans 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 we do
Hi all,
On Tue, Nov 25, 2014 at 8:09 PM, Andrea Faulds 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 "\u{code point}
On Tue, 25 Nov 2014, Dmitry Stogov wrote:
> On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds wrote:
>
> >
> > > On 25 Nov 2014, at 08:33, Dmitry Stogov wrote:
> > >
> > > May be I misunderstood something, but why to introduce unicode escapes
> > if PHP engine doesn't support Unicode.
> >
> > We d
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.
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
> On 25 Nov 2014, at 11:20, Alain Williams 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 way of en
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 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 U
> On 25 Nov 2014, at 10:41, Dmitry Stogov wrote:
>
> u8"string" 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 UTF-8-compatible
> On 25 Nov 2014, at 10:32, Derick Rethans 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 Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds wrote:
>
> > On 25 Nov 2014, at 08:33, Dmitry Stogov 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
On Mon, 24 Nov 2014, Sara Golemon wrote:
> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds 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, and r
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 Nov 2014, at 08:33, Markus Fischer 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 practices
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, Dmitry Stogov 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 strings as UTF
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
http://www.php.net
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
37 matches
Mail list logo
