Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Sebastian Bergmann]

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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Bob Weinand]

> 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 risk, but it's the kind of change
>> that wouldn't break anything without it being tremendously obvious.
> 
> I agree and we should be still in time for RC8.
> 
> 
> Cheers
> -- 
> Matteo Beccati

Hey,

I fixed the issue via 
http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254

I think too this should go into PHP 7.0.0 as it is some type of a language 
related change (even if not directly failing in parser...)

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Chris Riley]

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.

>>>
>>> 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 also what I'd expect. However, "int" is not allowed as a class name
> in PHP 7. And unfortunately what the code Sebastian posted sctually does is
> act as an integer type hint, not as a class type hint.
>
> Can this be fixed for 7.0.0?
>>>
>>
>> I don't think this would be a good idea. We're in the final stretch of
>> release cycle, and should not do any non-urgent fixes. This does not
>> look urgent. It can wait for 7.0.1.
>>
>
> 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.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Could we not just document it as \int is not allowed and throws a fatal
error. Then we'd just be fixing a bug in documented behaviour.

~C

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Stanislav Malyshev]

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. We can put a note in release notes for this is needed. But the
risk of changing syntax parts on the brink of GA IMHO is much larger
than the risk of somebody using \int in 7.0.0 and getting breakage in
7.0.1. Especially if it's clearly described as a bug we intend to fix.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

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 feel too bad for breaking that
code. We can put a note in release notes for this is needed. But the
risk of changing syntax parts on the brink of GA IMHO is much larger
than the risk of somebody using \int in 7.0.0 and getting breakage in
7.0.1. Especially if it's clearly described as a bug we intend to fix.


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 anything without it being tremendously obvious.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Joshua Holmer]

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
> immediately jumps to using \int, I don't feel too bad for breaking that
> code. We can put a note in release notes for this is needed. But the
> risk of changing syntax parts on the brink of GA IMHO is much larger
> than the risk of somebody using \int in 7.0.0 and getting breakage in
> 7.0.1. Especially if it's clearly described as a bug we intend to fix.
>

Hi,

Isn't it quite worse to fix this in a patch release than to fix it prior to
GA? If something like this breaks prior to GA, that's tolerated. People
have been warned not to use pre-release versions of PHP7 in production.
Once 7.0.0 is out, people expect stability. If something breaks between
patch releases, even an undocumented behavior like this, it makes PHP look
bad. Even if you call this change a bug fix, there's no reason not to put
it in now, since isn't the purpose of the RCs to fix as many bugs as
possible before GA?

Josh Holmer

[PHP-DEV] PHP 7.0.0 final RTM delay

[Anatol Belski]

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 the 
bugs considered security relevant. Those still might be applied, if any.

Looking straight forward to 7.0.0 RTM!

Thanks everyone

Anatol
  

Re: [PHP-DEV] Native Annotation Syntax

[Benjamin Eberlei]

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 find a discussion for it anywhere. The second one, which proposes
> retrieving annotation from DocBlocks through reflection is 'inactive', with
> no further explanation.
>
> I'd really like to see native annotation support for PHP that doesn't live
> in comments.
>
> Is there a reason those RFCs were dropped, or was it just lack of interest?
>

There was a vote on the declined one from Guilherme, which was in the old
mailing list style,
you'd have to search the mailing ilst archives to find the thread with the
discussion and voting.

>
> - Pedro.
>

[PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

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.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Stanislav Malyshev]

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 class of that name
> rather than a scalar type.

I would assume \int means class named "int", as opposed to "int" type.
But banning it may be ok too.

> 
> Can this be fixed for 7.0.0?

I don't think this would be a good idea. We're in the final stretch of
release cycle, and should not do any non-urgent fixes. This does not
look urgent. It can wait for 7.0.1.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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
retrieving annotation from DocBlocks through reflection is 'inactive', with
no further explanation.

I'd really like to see native annotation support for PHP that doesn't live
in comments.

Is there a reason those RFCs were dropped, or was it just lack of interest?

- Pedro.

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Andrea Faulds]

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 also what I'd expect. However, "int" is not allowed as a class 
name in PHP 7. And unfortunately what the code Sebastian posted sctually 
does is act as an integer type hint, not as a class type hint.



Can this be fixed for 7.0.0?


I don't think this would be a good idea. We're in the final stretch of
release cycle, and should not do any non-urgent fixes. This does not
look urgent. It can wait for 7.0.1.


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.


Thanks.

--
Andrea Faulds
http://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Anthony Ferrara]

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 problem. We should fix that prior to gold. I'll take a
peak at it when I get some time, but if someone else has a few minutes
and wants to tackle it go for it.

Anthony

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Native Annotation Syntax

[Rowan Collins]

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 anywhere. The second one, which proposes
retrieving annotation from DocBlocks through reflection is 'inactive', with
no further explanation.

I'd really like to see native annotation support for PHP that doesn't live
in comments.

Is there a reason those RFCs were dropped, or was it just lack of interest?


I think one of the stumbling blocks in recent discussions of annotation 
support is just how much support should be provided; off the top of my 
head, this could be:


- a few extra functions in reflection classes to parse the items within 
a docblock (docblocks are already handled in reflection separately from 
normal comments)
- automatic instantiation of a set of standard Annotation objects with 
the text content above

- automatic instantiation of classes based on the annotations provided
- built-in support for applying annotations to the objects they appear 
on, perhaps in the form of full Aspect-Oriented Programming support


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, or a parseable PHP expression? is it more 
useful to use the de facto existing syntax in DocBlocks, or to add a new 
keyword or operator? etc


The devil, as ever, is in the detail.

Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[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 risk, but it's the kind of change
> that wouldn't break anything without it being tremendously obvious.

I agree and we should be still in time for RC8.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Native Annotation Syntax

[Sara Golemon]

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, or a parseable PHP expression? is it more useful to use the de facto
> existing syntax in DocBlocks, or to add a new keyword or operator? etc
>
If we're going to use something in the docblock, then I wouldn't want
it parsed on compilation, but rather have it be an on-demand parse
while reflecting.  The reason being that there are plenty of
docblock'd PHP libraries out there using invalid annotations because
they're not running it through tools to tell them what they got wrong.
Waiting till they've actually tried to examine it through reflection
lets us throw an exception on code that cares about it rather than
preventing code which ignores reflection from running.

I, for one, am a fan of Java style annotations which allow a string
name plus optional metadata.

@@foo
class Bar {
  @@Baz("something", 123, [ 'a', 'b', ''c'])
  public function qux() { ... }
}

Though the formality of having to define the annotation as an
interface is a bit overkill for PHP, the same rules Hack uses would be
clear and simple enough:

<>
class Bar {
  <>
  public function qux() { ... }
}

And no, I'm not picky about the parser symbol used...  In fact,
allowing an optional '//' prefix to annotations might be nice for
compatibility.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Xinchen Hui]

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 around with
> >> the parser.
> >>
> >> I understand your concern about the risk, but it's the kind of change
> >> that wouldn't break anything without it being tremendously obvious.
> >
> > I agree and we should be still in time for RC8.
> >
> >
> > Cheers
> > --
> > Matteo Beccati
>
> Hey,
>
> I fixed the issue via
> http://git.php.net/?p=php-src.git;a=commitdiff;h=569763cb1ac67f56e7743062ca8b3b7c650c1254
>
> I think too this should go into PHP 7.0.0 as it is some type of a language
> related change (even if not directly failing in parser...)
>
>
I've made a improvement to the fix(
https://github.com/php/php-src/commit/00865ae22f2c5fdee9e500ce79d442467e0a0899)
,

before this, \array will result a syntax , but \int result a compiler
error, which seems a little in-consistent.

thanks

> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] 7.0.0 release

[Rafael Dohms]

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 (needs
> definition of stable and probably an RFC)
>



C would be ideal.
Give everyone a chance to validate the count fix, plus its a nice date that
does not leave Americans
up in arms about turkeys and its way before christmas, very neutral ground


-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl 

Re: [PHP-DEV] 7.0.0 release

[Julien Pauli]

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
>>>
>>> +1
>>
>>
>> +1
>
> +1
>
> With one important mod - of course there'll be bugs coming in.  But much like 
> you said, if they're the kind we see on the change log of every bug fix 
> release we do (like between RC7 and RC8), let's not delay the release for 
> them.  Delaying the release further should be for truly disastrous bugs.

+1

We have to take care of December, 3rd is OK, later can be a problem
(Xmas approaching, etc...)


Julien

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Sebastian Bergmann]

 The following is currently valid PHP 7 code

 http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Ryan Pallas]

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 type, you can prefix a \ on any other root level
type that's valid for use in type hinting.

function a(\DateTime $d) {}
function b(\SplFileObject $f) {}

Also, this is the only way to get some IDEs to recognize the type when in a
namespace (at least currently).

[PHP-DEV] Benchmark Results for PHP Master 2015-11-24

[lp_benchmark_robot]

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:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-)   Wordpress 4.2.2 cgi -T1  0.11%  0.09%  2.81%  
  7.37%
:-|   Drupal 7.36 cgi -T1  0.73% -0.21% -0.08%  
  5.09%
:-)   MediaWiki 1.23.9 cgi -T5000  0.60%  0.56%  1.87%  
  3.96%
:-) bench.php cgi -T1  0.13%  1.16%  2.65%  
  6.40%
:-(   micro_bench.php cgi -T1  0.07% -1.42%  0.40%  
  6.11%
:-)mandelbrot.php cgi -T1  0.07%  1.23%  0.86%  
  6.55%
---
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Internal methods proposal

[Dominic Grostate]

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 being used in ways unintended,
while still allowing classes within the same namespace to interact with
each other non-api methods.

I've created a commit:
https://github.com/orolyn/php-src/commit/2ddec7149c308a80b33653da31b5ba214f679bb8

Please forgive any mistakes, it is a proof of concept and just complete
enough to fulfil the feature.

Currently, a limitation is internal methods can only be called from within
another scope in the same namespace, as opposed to outside a class.

For this implementation I needed to store the namespace of the class during
the declaration, so to test that I added the function get_class_namespace
to help me iron out some bugs.  I have left the function there.

Thank you,
Dominic

Re: [PHP-DEV] Internal methods proposal

[Rowan Collins]

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 as "package 
visibility", "namespace visibility", "private class", and the related 
notion of "friend class" / "friend function".


I wonder if we should maintain a Usenet-style FAQ for this list, to make 
it easier to find what has previously been discussed on a topic.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Xinchen Hui]

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) continue issuing release candidates till it's stable enough (needs
> > definition of stable and probably an RFC)
> >
> > I would really ask to reach a consent on either a) or c). IMO, the
> options
> > b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> > release just to release, but it is definitely harmful to slow down the
> rise.
> >
> > Thanks
> >
> > Anatol
> >
>
> 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.
>
> We all know the "real testing" doesn't begin until it's released, and the
> best way to find what is left (things we have not found in over a year of
> development and testing), is to get more people looking at it.
>
> Delaying the release is actually delaying the discovery of bugs that affect
> real world applications that we do not have access to, and cannot test
> with. Many teams will not even start testing with 7 until it gets an
> official release.
>
I agree.

I also go for a)

thanks

>
> If something is found, it doesn't make the release any less high quality.
> Any bugs that would be found between now and the 3rd will still be found
> (and probably more), and they will still be fixed. The only difference
> would be a 0.0.1 version number.
>
> /2c
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

Re: [PHP-DEV] 7.0.0 release

[Leigh]

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
> definition of stable and probably an RFC)
>
> I would really ask to reach a consent on either a) or c). IMO, the options
> b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> release just to release, but it is definitely harmful to slow down the rise.
>
> Thanks
>
> Anatol
>

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.

We all know the "real testing" doesn't begin until it's released, and the
best way to find what is left (things we have not found in over a year of
development and testing), is to get more people looking at it.

Delaying the release is actually delaying the discovery of bugs that affect
real world applications that we do not have access to, and cannot test
with. Many teams will not even start testing with 7 until it gets an
official release.

If something is found, it doesn't make the release any less high quality.
Any bugs that would be found between now and the 3rd will still be found
(and probably more), and they will still be fixed. The only difference
would be a 0.0.1 version number.

/2c

[PHP-DEV] Re: Internal methods proposal

[Dominic Grostate]

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 as "package visibility", "namespace visibility", "private class", and
the related notion of "friend class" / "friend function". I wonder if we
should maintain a Usenet-style FAQ for this list, to make it easier to find
what has previously been discussed on a topic. Regards, -- Rowan Collins
[IMSoP]

Ah yes, I've seen them in the request bugs.
https://bugs.php.net/bug.php?id=52297

It was suggested that a prototype be made, I have provided one, and it
should pass basic demos.  I just didn't want to take it further than that
unless it generate some interest.

[PHP-DEV] Re: Internal methods proposal

[Rowan Collins]

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 searching for threads on a list 
archive using terms such as "package visibility", "namespace 
visibility", "private class", and the related notion of "friend class" 
/ "friend function". I wonder if we should maintain a Usenet-style FAQ 
for this list, to make it easier to find what has previously been 
discussed on a topic. Regards, -- Rowan Collins [IMSoP]


Ah yes, I've seen them in the request bugs.
https://bugs.php.net/bug.php?id=52297

It was suggested that a prototype be made, I have provided one, and it 
should pass basic demos.  I just didn't want to take it further than 
that unless it generate some interest.




I was thinking more of recent threads on this list, such as these:

http://marc.info/?l=php-internals=144608749903477=2
http://marc.info/?t=14472015471=1=2
http://marc.info/?t=14463939791=1=2

There are probably more if you search around, and a couple of people do 
seem to be working on prototypes.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[David Zuelke]

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 golden version. Otherwise, another RC. Rinse and repeat.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Theodore Brown]

> 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 type, you can prefix a \ on any other root level
> type that's valid for use in type hinting.
>
> function a(\DateTime $d) {}
> function b(\SplFileObject $f) {}
>
> Also, this is the only way to get some IDEs to recognize the type when in a
> namespace (at least currently).

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.
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Sebastian Bergmann]

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

Re: [PHP-DEV] Scalar Type Declaration Syntax Weirdness

[Sebastian Bergmann]

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, for instance, is a built-in class
 whereas int is a type (I know that classes are types but you know what I
 mean).

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 7.0.0 release

[Bishop Bettini]

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 (needs
> definition of stable and probably an RFC)
>
> I would really ask to reach a consent on either a) or c). IMO, the options
> b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> release just to release, but it is definitely harmful to slow down the rise.
>

The little poll I sent yesterday in response to Phil's email has an even
split.

Question: Create an RC for this count($array) fix?
Responses: 26 for, 26 against
http://poll.pollcode.com/92997454_result?v

Maybe all it says is the community is split, and we won't reach consensus.

So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :)

Re: [PHP-DEV] 7.0.0 release

[guilhermebla...@gmail.com]

+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, 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
> > definition of stable and probably an RFC)
> >
> > I would really ask to reach a consent on either a) or c). IMO, the
> options
> > b) and d) are the direct road to curbing 7.0.0.  There is no hurry to
> > release just to release, but it is definitely harmful to slow down the
> rise.
> >
>
> The little poll I sent yesterday in response to Phil's email has an even
> split.
>
> Question: Create an RC for this count($array) fix?
> Responses: 26 for, 26 against
> http://poll.pollcode.com/92997454_result?v
>
> Maybe all it says is the community is split, and we won't reach consensus.
>
> So while I'm +1 on (c), I defer to the wisdom and guidance of our RMs. :)
>



-- 
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada