On Mon, Jan 5, 2015 at 11:42 PM, Jacob Bednarz wrote:
> Hey
>
>> That reminds me something I was wondering, would it be possible to
>> have a kind of CS check on push? :)
>
>
> Yep - PHPCS[1] is quite good, easy to configure and has good editor
> integrations in the community. The automated code s
Hey
That reminds me something I was wondering, would it be possible to
have a kind of CS check on push? :)
Yep - PHPCS[1] is quite good, easy to configure and has good editor
integrations in the community. The automated code standards check can be
achieved using git-hooks[2] which is already
On Mon, Jan 5, 2015 at 10:48 PM, Pierre Joye wrote:
> For example HHVM provides a neat one, which is simply PHP for simple
> cases. Complex cases allow advanced the native support is also
> supported. See https://github.com/facebook/hhvm/wiki/Extension-API.
... Complex cases can be implemented u
hi,
On Mon, Jan 5, 2015 at 8:21 PM, François Laupretre wrote:
>> -Message d'origine-
>> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
>>
>> So, I've been meaning to propose something *like* this, but with a few
>> key implementation detail differences:
>>
>> 1
On Mon, Jan 5, 2015 at 2:58 PM, Stanislav Malyshev wrote:
> Hi!
>
> The code in the PHP source repo has a lot of random dangling whitespace
> at the end of lines, which looks sloppy and produces some weird effects
> in diffs because some editors auto-clean it and some do not. I'd like to
> clean i
hi :)
On Mon, Jan 5, 2015 at 9:08 AM, Xinchen Hui wrote:
> Hey:
>
> I was working on zend_qsort improvement. but I got a problem need
> to be disscussed with you fist..
>
> as we know, previously zend_qsort is not a stable sorting algo.
>
> my draft patch (which already get 0.1% I
> -Message d'origine-
> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
>
> So, I've been meaning to propose something *like* this, but with a few
> key implementation detail differences:
>
> 1) Create the notion of "Persistent User Functions/Classes/Constants/et
On 5 January 2015 at 18:39, Xinchen Hui wrote:
> On Tue, Jan 6, 2015 at 2:04 AM, Tim Düsterhus wrote:
>> On 05.01.2015 18:08, Xinchen Hui wrote:
>>> do you think such BC break is acceptable? or I still need a RFC? :<
>>>
>>
>> Chiming in as a pure userland developer. The documentation already
On Tue, Jan 6, 2015 at 2:04 AM, Tim Düsterhus wrote:
> On 05.01.2015 18:08, Xinchen Hui wrote:
>> do you think such BC break is acceptable? or I still need a RFC? :<
>>
>
> Chiming in as a pure userland developer. The documentation already states:
>
>> Note: Like most PHP sorting functions, so
On Tue, Jan 6, 2015 at 2:12 AM, David Zuelke wrote:
> This sounds reasonable, because given how the sort is *not* stable, there
> will be other cases (totally made up, but let's say ["a", "o", "O"]) where
> the swap does *not* happen. Consistency, and thus a stable sort, is better.
yeah, I also
> I’m not saying change existing APIs. I’m saying add new, parallel ones.
We’ve done this before, we can do it again. It doesn’t break BC.
Makes sense to have new better overlapping APIs while old ones are slowly
deprecated (which is still a (delayed) BC break). Thanks for clarifying
this, anyway.
Hey Stas,
> On 5 Jan 2015, at 22:58, Stanislav Malyshev wrote:
>
> The code in the PHP source repo has a lot of random dangling whitespace
> at the end of lines, which looks sloppy and produces some weird effects
> in diffs because some editors auto-clean it and some do not. I'd like to
> clean
On 05/01/15 22:58, Stanislav Malyshev wrote:
> So, I'd like to ask if there are any objections to such cleanup? If not,
> then I'll do it, probably next weekend.
The bigger question is perhaps how they got added in the first place.
(And it's a bit like replacing all the tabs with spaces.) I've bee
Hi Marcio,
> On 5 Jan 2015, at 23:14, Marcio Almada wrote:
>
> Not sure how this RFC rant is helpful since it's based on completely unreal
> alternatives. This "We should get better APIs instead" suggestion, in
> practice, means a ton of BC breaks that will never happen on PHP global
> functions
Hi,
Stanislav, great RFC. A huge part of core PHP API would benefit of
parameter skipping.
Andrea Faulds,
> It’s not that I don’t need this… there are some horrible APIs I’ve used
which would be slightly (but only slightly) more pleasant to use with this
feature. But I don’t think we should add
On Mon, Jan 5, 2015 at 11:58 PM, Stanislav Malyshev
wrote:
> Hi!
>
> The code in the PHP source repo has a lot of random dangling whitespace
> at the end of lines, which looks sloppy and produces some weird effects
> in diffs because some editors auto-clean it and some do not. I'd like to
> clean
Hi!
The code in the PHP source repo has a lot of random dangling whitespace
at the end of lines, which looks sloppy and produces some weird effects
in diffs because some editors auto-clean it and some do not. I'd like to
clean it up (it's easy to do automatically) in master, but this produces
a bi
Hi!
> Sure, but things like this make such APIs easier to work with. That’s
> not a good thing.
For me, it is. Your stance is "if it's not ideal (in my opinion) design,
we should not do anything to make it better". I think it's wrong - there
are many opinions about what ideal design is, and yours
Hi Stas,
> On 5 Jan 2015, at 22:24, Stanislav Malyshev wrote:
>
> Hi!
>
>> Yes, they complement one another. Both exist because of horrible
>> APIs. But I don’t think we should encourage horrible APIs.
>
> You can create horrible APIs with this, but you can also create them
> without this. Thi
Hi!
> Yes, they complement one another. Both exist because of horrible
> APIs. But I don’t think we should encourage horrible APIs.
You can create horrible APIs with this, but you can also create them
without this. This doesn't make it any more likely, it just makes
working with optional paramete
Hi Stas,
> On 5 Jan 2015, at 22:02, Stanislav Malyshev wrote:
>
> For those who doesn't remember, quick reminder - it is about an ability
> to skip parameters in function calls so they'd take default value, like
> this:
> function foo($a, $b = true, $c = "abc") { ... }
> foo($x, default, $y); //
On Mon, Jan 5, 2015 at 9:30 PM, Andrea Faulds wrote:
>
> > On 5 Jan 2015, at 20:28, Stanislav Malyshev wrote:
> >
> > Hi!
> >
> >> usually each BC break would warrant an RFC and a vote, but I'm not sure
> >> many people would use str_replace("foo", array("bar"), $subject); and
> >> expect the im
On Mon, Jan 5, 2015 at 9:28 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > usually each BC break would warrant an RFC and a vote, but I'm not sure
> > many people would use str_replace("foo", array("bar"), $subject); and
> > expect the implicit array to string conversion of array("bar") => "Array"
> >
Hi!
As I've got some questions on the topic, I'd like to revive and soon put
to vote the parameter skipping RFC: https://wiki.php.net/rfc/skipparams
For those who doesn't remember, quick reminder - it is about an ability
to skip parameters in function calls so they'd take default value, like
this
On 16/12/2014 09:34, Stanislav Malyshev wrote:
I'd like to initiate a vote on "objects as keys" RFC:
https://wiki.php.net/rfc/objkey
Hi,
After discussing this RFC with other members of AFUP, we would probably
be +1 on the idea of being able to really use objects as keys.
But, considering thi
Hi!
> 1) Create the notion of "Persistent User
> Functions/Classes/Constants/etc...". This is an important perf item
> as reloading a prepend file on EVERY request is costly. Less costly
> with an opcache, sure, but still costly. Making the entries
> persistent lets us deal with this once in th
> On 5 Jan 2015, at 20:28, Stanislav Malyshev wrote:
>
> Hi!
>
>> usually each BC break would warrant an RFC and a vote, but I'm not sure
>> many people would use str_replace("foo", array("bar"), $subject); and
>> expect the implicit array to string conversion of array("bar") => "Array"
>> whic
Hi!
> usually each BC break would warrant an RFC and a vote, but I'm not sure
> many people would use str_replace("foo", array("bar"), $subject); and
> expect the implicit array to string conversion of array("bar") => "Array"
> which also emits a notice.
> let's see what others think.
I wouldn't
On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei wrote:
> I want to open discussion on my RFC to strengthen the ability of extensions
> to provide functionality to developers in both C **and** PHP code.
>
> For this extensions can add PHP files to a list of "prepend files" that are
> part of every
On Sat, Jan 3, 2015 at 1:55 PM, Nikita Popov wrote:
> Hi internals!
>
> I'd like to propose removing support for hexadecimal strings in the
> is_numeric_string() function, in order to achieve consistency with ordinary
> integer and float casts:
>
> https://wiki.php.net/rfc/remove_hex_support_
Sorry if someone receives this reply twice. I sent it by a different
alias by accident and apparently the sender confirmation does not work
properly.
On 05.01.2015 18:08, Xinchen Hui wrote:
> do you think such BC break is acceptable? or I still need a RFC?
>
Chiming in as a pure userland deve
On 05.01.2015 18:08, Xinchen Hui wrote:
> do you think such BC break is acceptable? or I still need a RFC? :<
>
Chiming in as a pure userland developer. The documentation already states:
> Note: Like most PHP sorting functions, sort() uses an implementation
of » Quicksort. The pivot is chose
This sounds reasonable, because given how the sort is *not* stable, there will
be other cases (totally made up, but let's say ["a", "o", "O"]) where the swap
does *not* happen. Consistency, and thus a stable sort, is better.
But you're saying your patch is "kind of a" stable sorting algo, so is
On Mon, Jan 5, 2015 at 6:20 PM, Andrea Faulds wrote:
> Hey François,
>
> > On 5 Jan 2015, at 17:15, F & N Laupretre wrote:
> >
> > I just created a PR for a feature request lying around since 2006 :
> >
> > https://github.com/php/php-src/pull/980
> >
> > It adds support in str_replace() and str_
Sounds more like a bugfix to me and def'ly an acceptable BC break in
either case. The behavior isn't specified and if anything I would
assume there _wouldn't_ be a swap with SORT_FLAG_CASE on. Interesting
though that many sorting examples (across languages) sidestep this
clearly common case.
-- S.
Hey：
> On Jan 6, 2015, at 1:27 AM, Julien Pauli wrote:
>
>> On Mon, Jan 5, 2015 at 6:09 PM, Xinchen Hui wrote:
>> On Tue, Jan 6, 2015 at 1:08 AM, Xinchen Hui wrote:
>> > Hey:
>> >
>> > I was working on zend_qsort improvement. but I got a problem need
>> > to be disscussed with you fist..
On Mon, Jan 5, 2015 at 6:09 PM, Xinchen Hui wrote:
> On Tue, Jan 6, 2015 at 1:08 AM, Xinchen Hui wrote:
> > Hey:
> >
> > I was working on zend_qsort improvement. but I got a problem need
> > to be disscussed with you fist..
> first
> >
> > as we know, previously zend_qsort is not a st
Hey François,
> On 5 Jan 2015, at 17:15, F & N Laupretre wrote:
>
> I just created a PR for a feature request lying around since 2006 :
>
> https://github.com/php/php-src/pull/980
>
> It adds support in str_replace() and str_ireplace() for the combination of
> (string needle, array replace). I
Ah gotcha — ok, awesome. Good work!
> On Jan 4, 2015, at 8:09 PM, François Laupretre wrote:
>
>> De : Martin Amps [mailto:ph...@rtin.so]
>
>> Did you mean to omit the “return” for is_cacheable_stream_path if
> !PHP_STREAMS_SUPPORT_IS_CACHEABLE?
>
> Right. Thanks for this one. Actually, condit
Hi,
I just created a PR for a feature request lying around since 2006 :
https://github.com/php/php-src/pull/980
It adds support in str_replace() and str_ireplace() for the combination of
(string needle, array replace). In this case, each occurrence of the needle
is replaced with an element f the
On Tue, Jan 6, 2015 at 1:08 AM, Xinchen Hui wrote:
> Hey:
>
> I was working on zend_qsort improvement. but I got a problem need
> to be disscussed with you fist..
first
>
> as we know, previously zend_qsort is not a stable sorting algo.
>
> my draft patch (which already get 0.1% IR
On Sun, Jan 4, 2015 at 2:21 PM, Derick Rethans wrote:
> On Fri, 2 Jan 2015, Sara Golemon wrote:
>
> >
> > > It was deliberate, I did it. The reason for getting rid of it was
> because it makes checking ZE2 simpler, actually. I didn't want to have to
> do #if defined(ZEND_ENGINE_2) && !defined(ZEN
Hey:
I was working on zend_qsort improvement. but I got a problem need
to be disscussed with you fist..
as we know, previously zend_qsort is not a stable sorting algo.
my draft patch (which already get 0.1% IRs reduce in wordpress)
is kindof a stable sorting algo, you can find it
On Mon, Jan 5, 2015 at 5:26 PM, Rowan Collins
wrote:
> Julien Pauli wrote on 05/01/2015 16:19:
>
>> Hello.
>>
>> Can't this be already done somehow ? In RINIT stage obviously.
>> I don't understand why to change our API to add a feature we already can
>> use ?
>>
>> Julien.P
>>
>
> The RFC explai
On Jan 5, 2015 10:41 PM, "Benjamin Eberlei" wrote:
>
>
> On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye wrote:
>>
>> Hi,
>>
>> On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" wrote:
>> >
>> > Hey everyone,
>> >
>> > I want to open discussion on my RFC to strengthen the ability of
extensions
>> > to prov
On Sun, Jan 4, 2015 at 1:57 AM, Sara Golemon wrote:
> On Sat, Jan 3, 2015 at 3:42 PM, Nikita Popov wrote:
> > Or maybe be more explicit and use "cstr" for C strings. (For symmetry the
> > zend_string type could become zstr.)
> >
> I personally prefer cstr/zstr for explicitness, but agree that th
Julien Pauli wrote on 05/01/2015 16:19:
Hello.
Can't this be already done somehow ? In RINIT stage obviously.
I don't understand why to change our API to add a feature we already can
use ?
Julien.P
The RFC explains the motivation reasonably clearly. In particular:
> Using RINIT is error pron
On Sun, Jan 4, 2015 at 12:52 PM, Benjamin Eberlei
wrote:
> Hey everyone,
>
> I want to open discussion on my RFC to strengthen the ability of extensions
> to provide functionality to developers in both C **and** PHP code.
>
> For this extensions can add PHP files to a list of "prepend files" that
Benjamin Eberlei wrote on 04/01/2015 13:00:
Files must be either in the PHP include path, or via absolute path, for
example by putting them right next to the shared object (.so) files and
using the extension_dir path inside the code, see the following for an
example (a hacked approach):
https://g
On Mon, Jan 5, 2015 at 3:02 PM, Pierre Joye wrote:
> Hi,
>
> On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" wrote:
> >
> > Hey everyone,
> >
> > I want to open discussion on my RFC to strengthen the ability of
> extensions
> > to provide functionality to developers in both C **and** PHP code.
> >
>
Hi,
On Jan 4, 2015 6:52 PM, "Benjamin Eberlei" wrote:
>
> Hey everyone,
>
> I want to open discussion on my RFC to strengthen the ability of
extensions
> to provide functionality to developers in both C **and** PHP code.
>
> For this extensions can add PHP files to a list of "prepend files" that
On Sat, Jan 3, 2015 at 5:57 PM, Sara Golemon wrote:
> On Sat, Jan 3, 2015 at 3:42 PM, Nikita Popov wrote:
>> Or maybe be more explicit and use "cstr" for C strings. (For symmetry the
>> zend_string type could become zstr.)
>>
> I personally prefer cstr/zstr for explicitness, but agree that the
>
On Mon, Dec 29, 2014 at 1:08 AM, Kalle Sommer Nielsen wrote:
> Happy holidays (and the new year to come) internals
>
> With the ongoing effort to focus resources into PHP7, we are yet to
> elect a release master (or two) for PHP7.
>
> Since this is done traditionally by
> 'who-have-the-time-to-in
On Sat, Dec 27, 2014 at 4:45 AM, Pierre Joye wrote:
> On Dec 26, 2014 7:42 PM, "Xinchen Hui" wrote:
> >
> > Hey:
> >
> > On Fri, Dec 26, 2014 at 7:54 PM, Andrea Faulds wrote:
> > >
> > >> On 26 Dec 2014, at 05:57, Levi Morrison wrote:
> > >>
> > >>> On Thu, Dec 25, 2014 at 2:33 PM, Michael Wal
On Mon, Jan 5, 2015 at 5:18 AM, Juan Basso wrote:
> Hi,
>
> Everyone has any concern on the constant name as Andrea mentioned? Should
> we keep or rename it? If this name is fine and there is no other concerns
> probably in 3 days (when completes 2 weeks) this RFC can be moved to
> voting, right?
55 matches
Mail list logo
