On Fri, May 17, 2019 at 1:53 PM Dik Takken wrote:
> I just created a pull request that changes the array_merge /
> array_merge_recursive functions such that they allow being called
> without arguments:
>
> https://github.com/php/php-src/pull/4175
The change seems simple, and the idea is welcome.
On Fri, 17 May 2019 at 21:53, Dik Takken wrote:
> Hello,
>
> I just created a pull request that changes the array_merge /
> array_merge_recursive functions such that they allow being called
> without arguments:
>
> https://github.com/php/php-src/pull/4175
>
> This is my first attempt to contribut
I feel like changing the default value of $enableExceptions to TRUE
makes more sense since that is what you would expect from the original
function call as it stands and is the least breakage of anything
already existing (since making it a required variable would throw
ArgumentCountError for any ex
Hello,
I just created a pull request that changes the array_merge /
array_merge_recursive functions such that they allow being called
without arguments:
https://github.com/php/php-src/pull/4175
This is my first attempt to contribute, feedback is highly appreciated.
please advise on how to proce
Evening Internals
While reviewing a PR[1], which proposes to add two new methods to
ext/sqlite3, one being an option to toggle on/off, I've noticed that
there already is another method which also enables the extension to
toggle on/off behavior, in this case; whether or not to throw
exceptions inst
On Fri, May 17, 2019 at 9:56 AM Bishop Bettini wrote:
> Our Git FAQ[1] currently says (at the bottom):
>
> > What about commits that should not be merged upwards (say, only for 5.3)?
> Should you still merge them but make it so no changes actually take place?
> Otherwise, it will the next person
Our Git FAQ[1] currently says (at the bottom):
> What about commits that should not be merged upwards (say, only for 5.3)?
Should you still merge them but make it so no changes actually take place?
Otherwise, it will the next person merging that will have to deal with the
conflict (or worse, the c
On Fr, 2019-05-17 at 09:20 +0100, Peter Cowburn wrote:
> On Fri, 17 May 2019 at 09:15, Claude Pache
> wrote:
>
> >
> >
> >
> > >
> > > Le 17 mai 2019 à 09:35, Peter Bowyer
> > > a
> > écrit :
> > >
> > >
> > > This could be a good time to make all blocks on the page
> > > collapsible,
> >
> > There is no need for JavaScript: use (as progressive enhancement,
> > etc.)
> How will that work for the cli (e.g. php -i)?
The situation on CLI is arguably even worse with very long lists like that and
indeed
things like JS or details tags would obviously not work for that.
--
PHP Inter
On Fri, 17 May 2019 at 09:15, Claude Pache wrote:
>
>
> > Le 17 mai 2019 à 09:35, Peter Bowyer a
> écrit :
> >
> > This could be a good time to make all blocks on the page collapsible,
> with
> > a "Collapse/Expand all" link added at the top.
> >
> > All added as progressive enhancement, so peop
> Le 17 mai 2019 à 09:35, Peter Bowyer a écrit :
>
> This could be a good time to make all blocks on the page collapsible, with
> a "Collapse/Expand all" link added at the top.
>
> All added as progressive enhancement, so people with JavaScript disabled
> see everything.
There is no need for
If the problem is that (multiple) people find the page too long to scroll
through, we can add some JavaScript to the output to hide the stats by
default.
This could be a good time to make all blocks on the page collapsible, with
a "Collapse/Expand all" link added at the top.
All added as progress
12 matches
Mail list logo
