ext/session and ext/json are required by most apps.
Actually I stopped attempts to build it when I saw compilation errors in
ext/session.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 10:44 AM, Pierre Joye wrote:
> On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov wrote:
> > Oh, it's still in draft sta
On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov wrote:
> Oh, it's still in draft state.
> Too may extensions are missing ext/seesion, ext/json, ext/pdo.
> Only very simple tests may be done now, and they can't predict impact on
> real-life applications.
We may as well try to help here.
This patch
> On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds wrote:
> From what I can see, the larger PHP community is generally in favour of
> strict typing, and among them, the previous RFC revision was received quite
> poorly. Myself, I might have been somewhat happy with just weak hints, but it
> woul
Oh, it's still in draft state.
Too may extensions are missing ext/seesion, ext/json, ext/pdo.
Only very simple tests may be done now, and they can't predict impact on
real-life applications.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 12:54 AM, Andrea Faulds wrote:
>
> > On 14 Jan 2015, at 19:43, D
On 01/14/2015 07:24 PM, Xinchen Hui wrote:
> On Thu, Jan 15, 2015 at 1:53 AM, Julien Pauli wrote:
>> I obviously will help porting some of them.
> as I remembered, memcached and redis already be proted by demon at php.net
For memcached, do you mean this pull request?
https://github.com/php-memc
Hey:
On Thu, Jan 15, 2015 at 7:52 AM, Pierre Joye wrote:
> On Wed, Jan 14, 2015 at 9:09 PM, Stanislav Malyshev
> wrote:
>> Hi!
>>
>>> I made a PR here: https://github.com/php/php-src/pull/999 for reviewing
>>>
>>> in benchmark this can brings more than 30% performance gain in
>>> arra
Hey:
On Thu, Jan 15, 2015 at 1:53 AM, Julien Pauli wrote:
> Hello,
>
>
> Had a discussion with Rasmus today.
>
> It would be cool if we could have a PHP7 compat of our top-10 Pecl
> extensions before our first PHP7 RC.
>
> This will allow more people to help testing both PHP7 (some people may nee
Hi,
Here's a function definition :
#PHP proto: int newt_centered_window ( int $width , int $height [,
string $title=null ] )
return_type: int
arguments:
width:
type: int
height:
type: int
title:
type: str
On 14 January 2015 at 21:21, Michael Wallner wrote:
> * imagick
Most of the work was done while it was still called NG:
https://github.com/danack/imagick/tree/phpng . Which means that branch
probably won't work against master as there have been other small
changes.
btw It would be great if there
Andrea Faulds wrote:
> From what I can see, the larger PHP community is generally in favour
> of strict typing, and among them, the previous RFC revision was
> received quite poorly. Myself, I might have been somewhat happy with
> just weak hints, but it would upset an awful lot of developers who
hi Andrea,
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significan
On Wed, Jan 14, 2015 at 9:09 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I made a PR here: https://github.com/php/php-src/pull/999 for reviewing
>>
>> in benchmark this can brings more than 30% performance gain in
>> array_sort etc functions.
>>
>> tests fails are related to non-stable vs
On Wed, Jan 14, 2015 at 4:40 PM, Nikita Popov wrote:
> On Fri, Jan 2, 2015 at 5:04 PM, Nikita Popov wrote:
>
>> Hi internals!
>>
>> Voting on the removal of deprecated functionality in PHP 7 is now open:
>>
>> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes
>>
>> As req
hi,
On Wed, Jan 14, 2015 at 6:53 PM, Julien Pauli wrote:
> Hello,
>
>
> Had a discussion with Rasmus today.
>
> It would be cool if we could have a PHP7 compat of our top-10 Pecl
> extensions before our first PHP7 RC.
>
> This will allow more people to help testing both PHP7 (some people may need
Hi,
I'd like to propose an RFC to convert PCRE compilation E_WARNINGs to
E_RECOVERABLE_ERRORs, so I'm opening a prior discussion to see how viable
this could be.
The reason is quite simple. If userland code is using malformed regular
expressions, this is probably a programmer's mistake caused by
Hi!
> We’re definitely not going to have consensus on introducing both options as
> per this RFC. I for one think it’s the worst possible option.
I agree. Being wrong is bad, making a mistake is bad, but having split
personality language and not knowing in which world you are - or even
worse, ha
Hey Dmitry,
> On 14 Jan 2015, at 20:40, Dmitry Stogov wrote:
>
> In my opinion, version 0.1 was consistent enough.
>
> handling two different approaches just makes mess...
>
> We have internal function strlen(string $s), and it may be called with
> integer argument e.g. strlen(123) -> 3
> I t
Hi Marc,
> On 14 Jan 2015, at 19:01, Marc Bennewitz wrote:
>
> 1. Inconsistencies of ZPP and explicit casts
>
> In my opinion it should be the same if you call a function in weak type mode
> and calling a function in strict type mode with explicit cast.
>
> But that would require to remove in
Hi Marcio,
> On 14 Jan 2015, at 18:52, Marcio Almada wrote:
>
> We still have a BC break but now we also have code with **mutant** behavior
> that might become buggy (do unexpected things) if a `declare` is used. As a
> language user and a package maintainer it would be a huge problem. Imagine
Hi Rowan,
> On 14 Jan 2015, at 15:45, Rowan Collins wrote:
>
> Perhaps it would be clearer if the RFC (and the documentation, if this is
> accepted) referred to the non-strict as something other than "weak". It makes
> it sound like only a weak check will be performed, and some values of the
On 14/01/15 23:13, Christian Stocker wrote:
> Hi
>
> On 14.01.15 22:21, Michael Wallner wrote:
>> On 14/01/15 18:53, Julien Pauli wrote:
>>
>> After a quick glance at the PECL package stats (of packages wchich are
>> not already in kind of an exclusive/external maintainance status, and
>> which I
Hi Zeev,
> On 14 Jan 2015, at 13:35, Zeev Suraski wrote:
>
> I don’t think we’re ever going to get consensus. But judging by the feedback
> to the v0.1 version, I tend to disagree that the opposers would have blocked
> it. There were certainly opposers – but not that many of them as far as I
Hi
On 14.01.15 22:21, Michael Wallner wrote:
> On 14/01/15 18:53, Julien Pauli wrote:
>
> After a quick glance at the PECL package stats (of packages wchich are
> not already in kind of an exclusive/external maintainance status, and
> which I used to use, so maybe biased):
>
> * imagick
> * uplo
> On 14 Jan 2015, at 19:43, Dmitry Stogov wrote:
>
> Hi Andrea,
>
> Where can I get the code?
>
> Thanks. Dmitry.
Hey Dmitry,
The bigint-libtommath branch was merged back into the bigint branch since I
figured there was no point keeping them separate, even if the LibTomMath
backend isn’t
On 14/01/15 18:53, Julien Pauli wrote:
> Hello,
>
>
> Had a discussion with Rasmus today.
>
> It would be cool if we could have a PHP7 compat of our top-10 Pecl
> extensions before our first PHP7 RC.
>
> This will allow more people to help testing both PHP7 (some people may need
> some of the t
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string $s), and it may be called with
integer argument e.g. strlen(123) -> 3
I think user functions should follow the same rules.
If some rules are "bad", lets
Hi!
> It's not part of the original proposal, and I'm not sure how easy it
> would be to implement, but it sounds like a nice extension, I didn't
> think about it. Since the RFC is already in vote, I won't change it now,
Strike that, I was confused, for some reason I thought I've already put
it t
Hi!
> Is it possible to use the default parameter on inheritance?
>
> class Bar {
> function foo($a='a', $b='b') {}
> }
>
> class Baz extends Bar {
> function foo($a=default, $b=default) {
> // do something
> parent::foo($a, $b);
> }
> }
It's not part of the original
Hi Stas,
As I said, we should look at that patch as we implemented Named Parameters
there with everything you mentioned.
Cheers,
On Wed, Jan 14, 2015 at 3:23 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > -1 on this proposal
> >
> > +1 on named parameters
>
> Come on, we've already talked about it
Hi!
> -1 on this proposal
>
> +1 on named parameters
Come on, we've already talked about it like 20 times and it has special
paragraph in the RFC dedicated exactly to this. It's not instead named
params, we can do both.
> Pierrick and I both implemented this support for Annotations back in 2010
IR - Instruction Retired.
We measure them using callgrind to analyze micro-improvements.
See https://wiki.php.net/phpng#performance_evaluation for more details.
Thanks. Dmitry.
On Wed, Jan 14, 2015 at 5:56 PM, Alexander Kurilo wrote:
> Hi Xinchen,
>
>> my draft patch (which already get 0
Hi,
-1 on this proposal
+1 on named parameters
As of for this...
> > handy and easier. I could dig the archives but I don't remember what
> > was the reason why we rejected the idea back then.
>
> Bikeshedding about the syntax mostly, but that all pales compared to
> amount of work that needs t
Hi!
> I made a PR here: https://github.com/php/php-src/pull/999 for reviewing
>
> in benchmark this can brings more than 30% performance gain in
> array_sort etc functions.
>
> tests fails are related to non-stable vs stable sorting difference.
>
> anyway, I feel it's better to
On Wed, Jan 14, 2015 at 12:04 PM, Marcio Almada wrote:
> Hi Levi,
>
> It's nice to see this RFC in voting phase again so quickly :) I just have
> one question. Since we had some changes in the implementation will the
> previous votes be discarded?
>
> 2015-01-14 6:18 GMT-03:00 Levi Morrison :
>
>>
Am 14.01.2015 um 20:21 schrieb Adam Harvey:
On 14 January 2015 at 11:15, Marc Bennewitz wrote:
But I think adding "default" as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.
OMG you are right - my fault
I personally also don't li
> On 15/01/2015, at 06:33, Marcio Almada wrote:
>
> Marc Bennewitz, Stas,
>
>> But I think adding "default" as new keyword is a big BC break!
>> I personally also don't like it and asked myself why can't the parameter
> simply skipped?
>
> Default is already a reserved word AFAIK. But I've bee
Hi Andrea,
Where can I get the code?
Thanks. Dmitry.
On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov wrote:
> I'm really surprised by the results :)
> I'll try to find time for bigint on next week and play with it a bit.
>
> Thanks. Dmitry.
>
>
> On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds wr
Marc Bennewitz, Stas,
> But I think adding "default" as new keyword is a big BC break!
> I personally also don't like it and asked myself why can't the parameter
simply skipped?
Default is already a reserved word AFAIK. But I've been thinking about
alternatives to parameter skipping syntax which
On 14 January 2015 at 11:15, Marc Bennewitz wrote:
> But I think adding "default" as new keyword is a big BC break!
Default already is a keyword: http://php.net/switch. There's no BC break.
> I personally also don't like it and asked myself why can't the parameter
> simply skipped?
That was in
Hi Stas,
I really like this RFC. It makes it simple to use defined defaults
without the need to know about them of to updated.
But I think adding "default" as new keyword is a big BC break!
I personally also don't like it and asked myself why can't the parameter
simply skipped?
function
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Wednesday, January 14, 2015 10:16 AM
> On Wed, Jan 14, 2015 at 6:53 PM, Julien Pauli wrote:
>
> It would be cool if we could have a PHP7 compat of our top-10 Pecl
> extensions before our first PHP7 RC.
>
> hi,
>
> here are some download stat
Hi Levi,
It's nice to see this RFC in voting phase again so quickly :) I just have
one question. Since we had some changes in the implementation will the
previous votes be discarded?
2015-01-14 6:18 GMT-03:00 Levi Morrison :
> Dear Internals,
>
> I have moved the Return Types RFC[1] into voting
Hi Andrea,
I have some notes about this RFC from a users POV with only little
knowledge about internals.
I didn't read 100% of the theads of this RFC so I'm sorry if some notes
of this email was already discussed.
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the s
Andrea,
With all the respect this RFC is way worst than the v0.1:
We still have a BC break but now we also have code with **mutant** behavior
that might become buggy (do unexpected things) if a `declare` is used. As a
language user and a package maintainer it would be a huge problem. Imagine
how
I suppose http://pecl.php.net/package-stats.php could help there
Kind regards,
Wim
On 14/01/2015 18:53, Julien Pauli wrote:
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.
This will allow mor
On Wed, Jan 14, 2015 at 6:53 PM, Julien Pauli wrote:
> Hello,
>
>
> Had a discussion with Rasmus today.
>
> It would be cool if we could have a PHP7 compat of our top-10 Pecl
> extensions before our first PHP7 RC.
>
> This will allow more people to help testing both PHP7 (some people may need
> s
Hello,
Had a discussion with Rasmus today.
It would be cool if we could have a PHP7 compat of our top-10 Pecl
extensions before our first PHP7 RC.
This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.
So
On Tue, 2014-12-30 at 12:57 +, Craig Duncan (PHP) wrote:
> I'd be willing to spend some time on this. Presumably I'd need some
> authorised access to the bug tracker?
You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them
Andrea Faulds wrote on 14/01/2015 13:15:
Hi Thomas,
On 14 Jan 2015, at 13:04, Thomas Nunninger wrote:
Sorry, if my mail was not clear. My point was: If I write a library in strict
mode and someone else is using it from his non-strict mode, he can pass an
integer to myFunc() without an error
On Fri, Jan 2, 2015 at 5:04 PM, Nikita Popov wrote:
> Hi internals!
>
> Voting on the removal of deprecated functionality in PHP 7 is now open:
>
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes
>
> As requested, I've split this up in many individual votes, only some
>
On 14 January 2015 at 14:00, Pavel Kouřil wrote:
>
>
> PS: Personally, I find the "scalar" typehint idea useless and cannot
> find a real use case for it. Richard, would you mind giving an
> example?
>
The point of the 'scalar' typehint comes about because we need to reject
non compatible types.
2015-01-14 16:00 GMT+02:00 Pavel Kouřil :
> Hello,
>
> personally, as a language user, I really dislike the idea of both
> options for scalar type hinting to be the part of the language.
> Especially since you would have to declare the strict typing in each
> file (if you are going by 1 class per
On 01/14/2015 02:35 PM, Zeev Suraski wrote:
> I don’t think we’re ever going to get consensus. But judging by the
> feedback to the v0.1 version, I tend to disagree that the opposers would
> have blocked it. There were certainly opposers – but not that many of them
> as far as I could tell. I
Hi Xinchen,
my draft patch (which already get 0.1% IRs reduce in wordpress)
could you or anyone else help me understand what IR stands for?
Thanks in advance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
personally, as a language user, I really dislike the idea of both
options for scalar type hinting to be the part of the language.
Especially since you would have to declare the strict typing in each
file (if you are going by 1 class per file in a bigger project, that's
a LOT of declare dire
I don't see big problems committing this.
In some cases new sort() functions may provide different results, but they
are still valid, because the order of "equal" elements after sort is not
defined.
Thanks. Dmitry.
On Wed, Jan 14, 2015 at 12:59 PM, Xinchen Hui wrote:
> Hey:
>
> I made a PR
I don’t think we’re ever going to get consensus. But judging by the
feedback to the v0.1 version, I tend to disagree that the opposers would
have blocked it. There were certainly opposers – but not that many of them
as far as I could tell. I think it stood a good chance to pass at a 2/3.
Unlike
On 14 January 2015 at 09:41, Zeev Suraski wrote:
> > -Original Message-
> > From: Andrea Faulds [mailto:a...@ajf.me]
> > Sent: Wednesday, January 14, 2015 11:33 AM
> > To: Leigh
> > Cc: PHP Internals List
> > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
> >
> > Hi Leigh,
> >
> > >
Hi Thomas,
> On 14 Jan 2015, at 13:04, Thomas Nunninger wrote:
>
> Sorry, if my mail was not clear. My point was: If I write a library in strict
> mode and someone else is using it from his non-strict mode, he can pass an
> integer to myFunc() without an error. If I use this integer in my libr
Hi Andrea,
On 01/14/2015 11:20 AM, Andrea Faulds wrote:
Hi Thomas,
On 14 Jan 2015, at 10:08, Thomas Nunninger wrote:
$i = 1;
$a = myFunc( $i );
declare(strict_typehints=TRUE);
function myFunc( float $f )
{
return otherFunc( $f );
}
function otherFunc( float $f )
{
Hi again,
On Wed, Jan 14, 2015 at 1:21 PM, Andrea Faulds wrote:
> Hi Andrey,
>
>> On 14 Jan 2015, at 11:10, Andrey Andreev wrote:
>>
>> I don't understand why it should be a bad thing that the API author
>> forces rules on the consumer. The opposite is IMO fundamental to the
>> concept of an API
Hi Andrey,
> On 14 Jan 2015, at 11:10, Andrey Andreev wrote:
>
> I don't understand why it should be a bad thing that the API author
> forces rules on the consumer. The opposite is IMO fundamental to the
> concept of an API - the rules specified by the author are a contract
> that the consumer a
Hello,
On Wed, Jan 14, 2015 at 12:22 PM, Andrea Faulds wrote:
>
> Hi Julien,
>
>> On 14 Jan 2015, at 10:14, Julien Pauli wrote:
>>
>> Using declare() IMO, is a PITA.
>> Everything that can be done without the use of declare(), must be done
>> without declare().
>>
>> I would have prefered diffe
Hi Julien,
> On 14 Jan 2015, at 10:14, Julien Pauli wrote:
>
> Using declare() IMO, is a PITA.
> Everything that can be done without the use of declare(), must be done
> without declare().
>
> I would have prefered different syntax, like the ones we disccussed many
> years ago , having stric
Hi Thomas,
> On 14 Jan 2015, at 10:08, Thomas Nunninger wrote:
>
>
> $i = 1;
> $a = myFunc( $i );
>
> declare(strict_typehints=TRUE);
>
> function myFunc( float $f )
> {
>return otherFunc( $f );
> }
>
> function otherFunc( float $f )
> {
>...
> }
>
>
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significant revision t
Hi,
On 01/14/2015 10:32 AM, Andrea Faulds wrote:
Hi Leigh,
On 14 Jan 2015, at 09:17, Leigh wrote:
I really don't like this behaviour being changed at the call site. If
I design a function that I _know_ should only take a string, then I
want it to be an error if the user supplies anything els
Hey:
I made a PR here: https://github.com/php/php-src/pull/999 for reviewing
in benchmark this can brings more than 30% performance gain in
array_sort etc functions.
tests fails are related to non-stable vs stable sorting difference.
anyway, I feel it's better to ask you to do a
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Wednesday, January 14, 2015 11:33 AM
> To: Leigh
> Cc: PHP Internals List
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Hi Leigh,
>
> > On 14 Jan 2015, at 09:17, Leigh wrote:
> >
> > I really don't like thi
Hi Leigh,
> On 14 Jan 2015, at 09:17, Leigh wrote:
>
> I really don't like this behaviour being changed at the call site. If
> I design a function that I _know_ should only take a string, then I
> want it to be an error if the user supplies anything else, so that
> they know they messed up.
I d
Dear Internals,
I have moved the Return Types RFC[1] into voting phase. A few changes
have happened since it was originally announced but have been covered
by discussion.
Return types are now invariant. This means a sub-type must declare the
same return type as its super-type's method when overri
On 14 January 2015 at 00:16, Andrea Faulds wrote:
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RFC, and
> bumped its version to 0.2.
>
> Here: https://wiki.php.net/rfc/scalar_type_hints
>
> This is a new thread because I’ve made a significant revision to th
Hey Robert,
> On 14 Jan 2015, at 08:22, Robert Stoll wrote:
>
> I had a few thoughts on the new proposed declare(strict_typehints=TRUE);
> construct and I must say I do not really like that we would have different
> behaviour just based on a directive. This is quite ugly from a readability
>
Hi Andrea
> -Ursprüngliche Nachricht-
> Von: Andrea Faulds [mailto:a...@ajf.me]
> Gesendet: Mittwoch, 14. Januar 2015 01:17
> An: PHP Internals List
> Betreff: [PHP-DEV] [RFC] Scalar Type Hints v0.2
>
> Good evening,
>
> I’ve made some quite significant changes to my Scalar Type Hints RF
74 matches
Mail list logo
