Hey:
On Wed, Nov 25, 2015 at 4:49 AM, Bob Weinand wrote:
> > Am 24.11.2015 um 20:30 schrieb Matteo Beccati :
> >
> > On 24/11/2015 18:50, Andrea Faulds wrote:
> >> There's no syntax change. We'd be adding another fatal error to
> >> zend_compile.c triggered by a flag on the token. No messing a
On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins wrote:
> At first sight, these seem like details which could be tweaked later, but
> they make a difference to what syntax to standardise: is the annotation name
> just a string, or a valid class name? is the value of the annotation just a
> string,
> Am 24.11.2015 um 20:30 schrieb Matteo Beccati :
>
> On 24/11/2015 18:50, Andrea Faulds wrote:
>> There's no syntax change. We'd be adding another fatal error to
>> zend_compile.c triggered by a flag on the token. No messing around with
>> the parser.
>>
>> I understand your concern about the ri
On 11/24/2015 05:47 PM, Andrea Faulds wrote:
Can this be fixed for 7.0.0?
I sure hope so.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 24/11/2015 18:50, Andrea Faulds wrote:
> There's no syntax change. We'd be adding another fatal error to
> zend_compile.c triggered by a flag on the token. No messing around with
> the parser.
>
> I understand your concern about the risk, but it's the kind of change
> that wouldn't break anythi
On 24/11/2015 16:30, Pedro Cordeiro wrote:
I'd been reading some old RFCs recently, and I found two RFCs on the
subject of annotations, both by Guilherme Blanco. The first one, which
proposed a native syntax for annotations, is marked as 'declined', and I
couldn't find a discussion for it anywher
On Nov 24, 2015 12:28 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > It can't wait for 7.0.1, because banning this would be a
> > backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0 or
> > not fix it ever.
>
> In theory, yes. In practice, if somebody starts using 7.0.0 and
> immedi
Hi Stas,
Stanislav Malyshev wrote:
Hi!
It can't wait for 7.0.1, because banning this would be a
backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0 or
not fix it ever.
In theory, yes. In practice, if somebody starts using 7.0.0 and
immediately jumps to using \int, I don't fe
On 24 November 2015 at 17:16, Andrea Faulds wrote:
> Hi Stas,
>
> Stanislav Malyshev wrote:
>
>> Hi!
>>
>>>>>function a(\int $i) {}
Is it intentional that the \ in front of the "int" is allowed? IMHO,
this
confusing notation must not be allowed.
>>>
Hi!
> It can't wait for 7.0.1, because banning this would be a
> backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0 or
> not fix it ever.
In theory, yes. In practice, if somebody starts using 7.0.0 and
immediately jumps to using \int, I don't feel too bad for breaking that
code.
Hi Stas,
Stanislav Malyshev wrote:
Hi!
This is weird and I'd consider it a bug. You can't do \array or
\callable, and if I saw \int, I'd think it meant a class of that name
rather than a scalar type.
I would assume \int means class named "int", as opposed to "int" type.
That's als
Sebastian,
On Tue, Nov 24, 2015 at 10:10 AM, Sebastian Bergmann wrote:
> The following is currently valid PHP 7 code
>
>function a(\int $i) {}
>
> Is it intentional that the \ in front of the "int" is allowed? IMHO, this
> confusing notation must not be allowed.
Yeah, that is a pr
Hi!
>> > function a(\int $i) {}
>>
>> Is it intentional that the \ in front of the "int" is allowed? IMHO,
>> this
>> confusing notation must not be allowed.
>
> This is weird and I'd consider it a bug. You can't do \array or
> \callable, and if I saw \int, I'd think it meant a cl
Hi Sebastian,
Sebastian Bergmann wrote:
The following is currently valid PHP 7 code
This is weird and I'd consider it a bug. You can't do \array or
\callable, and if I saw \int, I'd think it meant a class of that name
rather than a scalar type.
Can this be fixed for 7.0.0?
Thanks
On Tue, Nov 24, 2015 at 5:30 PM, Pedro Cordeiro
wrote:
> Hello.
>
> I'd been reading some old RFCs recently, and I found two RFCs on the
> subject of annotations, both by Guilherme Blanco. The first one, which
> proposed a native syntax for annotations, is marked as 'declined', and I
> couldn't f
Hi,
based on the discussion of the last few days and the reached consent, the final
date of the 7.0.0 RTM is shifted. RC8 is planned to appear on November 26th
instead of GA. 7.0.0 RTM will follow shortly on December 3rd.
The final release is going to be identical to RC8 with the exception of t
Hello.
I'd been reading some old RFCs recently, and I found two RFCs on the
subject of annotations, both by Guilherme Blanco. The first one, which
proposed a native syntax for annotations, is marked as 'declined', and I
couldn't find a discussion for it anywhere. The second one, which proposes
ret
+1 on (a)
It's perfectly normal to have issues fixed between last RC and GA.
[]s,
On Tue, Nov 24, 2015 at 10:51 AM, Bishop Bettini wrote:
> On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski
> wrote:
>
> > a) release on 26th including all known bug fixes
> > b) do RC8, assume there are no bugs, s
On Mon, Nov 23, 2015 at 4:10 PM, Anatol Belski wrote:
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough (ne
On 11/24/2015 04:42 PM, Theodore Brown wrote:
The difference is that DateTime and \DateTime mean different things inside a
namespace.
int and \int always mean the same thing, so it seems confusing to allow the
latter syntax
as if it means something different.
That. And the fact that DateTime
On 11/24/2015 04:27 PM, Ryan Pallas wrote:
Also, this is the only way to get some IDEs to recognize the type when in a
namespace (at least currently).
Then the IDEs have to be fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Tue, Nov 24, 2015 at 8:10 AM, Sebastian Bergmann
> wrote:
>
>> The following is currently valid PHP 7 code
>>
>> > function a(\int $i) {}
>>
>> Is it intentional that the \ in front of the "int" is allowed? IMHO, this
>> confusing notation must not be allowed.
>>
>>
>> Why not? Its a root lev
On Tue, Nov 24, 2015 at 8:10 AM, Sebastian Bergmann
wrote:
> The following is currently valid PHP 7 code
>
>function a(\int $i) {}
>
> Is it intentional that the \ in front of the "int" is allowed? IMHO, this
> confusing notation must not be allowed.
>
>
> Why not? Its a root level
The following is currently valid PHP 7 code
http://www.php.net/unsub.php
Dominic Grostate wrote on 24/11/2015 12:33:
Dominic Grostate wrote on 24/11/2015 12:14: > I think this proposal
has been made before maybe here or discussed > elsewhere. Still, I'd
like to give my input on the idea. There have indeed been a couple of
discussions of this recently. Try searchi
On 24.11.2015, at 12:57, Leigh wrote:
> I prefer a over c.
>
> As you said, we can deliver a stable and high quality 7.0.0 today. An RC
> period where you expect no bugs does not sound productive to me.
That is exactly the point of an RC. No show-stoppers means you then roll the RC
out as the
Hey:
On Tue, Nov 24, 2015 at 7:57 PM, Leigh wrote:
> On 23 November 2015 at 21:10, Anatol Belski wrote:
>
> > a) release on 26th including all known bug fixes
> > b) do RC8, assume there are no bugs, so target 10th for RTM
> > c) do RC8, release on 3rd, expect there are no bugs come in
> > d) c
Dominic Grostate wrote on 24/11/2015 12:14: > I think this proposal has
been made before maybe here or discussed > elsewhere. Still, I'd like to
give my input on the idea. There have indeed been a couple of discussions
of this recently. Try searching for threads on a list archive using terms
such a
Dominic Grostate wrote on 24/11/2015 12:14:
I think this proposal has been made before maybe here or discussed
elsewhere. Still, I'd like to give my input on the idea.
There have indeed been a couple of discussions of this recently. Try
searching for threads on a list archive using terms such
Hi,
I think this proposal has been made before maybe here or discussed
elsewhere. Still, I'd like to give my input on the idea.
The basic concept is when a method has the internal access modifier, it can
only be called from within the same namespace.
The case for this is to protect classes from
Results for project PHP master, build date 2015-11-24 05:25:44+02:00
commit: c1b374554c86b19dd51b2e889e5d9b664485ab0e
revision date: 2015-11-23 19:02:41+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
mem
On 23 November 2015 at 21:10, Anatol Belski wrote:
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough (needs
On Mon, Nov 23, 2015 at 10:10 PM, Anatol Belski wrote:
>
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough
On Tue, Nov 24, 2015 at 7:27 AM, Zeev Suraski wrote:
>
>> On 24 בנוב׳ 2015, at 7:18, Davey Shafik wrote:
>>
>> On Tue, Nov 24, 2015 at 1:00 AM, Sebastian Bergmann
>> wrote:
>>
On 11/23/2015 10:10 PM, Anatol Belski wrote:
c) do RC8, release on 3rd, expect there are no bugs come in
34 matches
Mail list logo
