Sand Box: A first class API that allows unit testing of code with mocks
and stubs of other classes or functions, without the need to modify the
class under test.
This is an initial idea of how a Sand Box API could work:
$oSandbox = new SPLSandBox();
$oSandbox->MockFunction('\mocks\fopen','\fop
On 05.08.2024 at 21:37, Gina P. Banyard wrote:
> This sounds like a uopz extension issue that is easily fixed.
Most likely, yes, although still somebody has to provide a fix, and
someone has to do a new release.
> I am not sure why we should bend over backwards for extensions that allow to
> br
On 4 August 2024 13:08:22 BST, "Christoph M. Becker" wrote:
>On 04.08.2024 at 13:42, Nick Lockheart wrote:
>
>> To that end, I have created the following RFC:
>>
>> https://wiki.php.net/rfc/global_function_parser_directive
>> I am asking that we discuss and vote on the following question:
>
>Pl
On Monday, 5 August 2024 at 18:30, Christoph M. Becker
wrote:
> On 05.08.2024 at 18:52, Tim Düsterhus wrote:
>
> > On 8/5/24 14:52, Christoph M. Becker wrote:
> >
> > > Hmm, so far I only had skimmed the RFC and the related discussions, but
> > > now I checked out the suggested implementation[
On Mon, Aug 5, 2024, at 20:49, Ilija Tovilo wrote:
> On Mon, Aug 5, 2024 at 3:33 PM Nick Lockheart wrote:
> >
> > This is a different problem that could be solved by a sandbox API.
>
> Not sure which case we were talking about then. ClockMock is what I've
> been referencing all along.
>
> > >
On Monday, 5 August 2024 at 12:04, Derick Rethans wrote:
> On Tue, 30 Jul 2024, Christoph M. Becker wrote:
>
> > On 30.07.2024 at 11:49, Gina P. Banyard wrote:
> >
> > > I have just opened the vote for the "Transform exit() from a
> > > language construct into a standard function" RFC:
> > > ht
On Mon, Aug 5, 2024, at 19:03, Tim Düsterhus wrote:
> >>> If there is a function call to a function with a 'never' return
> >>> type, then that function will potentially throw, or exit.
> >>>
> >>> But that's not relevant for the analysis, as these userland
> >>> functions will have their own opa
On Mon, Aug 5, 2024 at 3:33 PM Nick Lockheart wrote:
>
> This is a different problem that could be solved by a sandbox API.
Not sure which case we were talking about then. ClockMock is what I've
been referencing all along.
> > Well, ok. But then we're back to prefixing global calls, which
> > de
On 05.08.2024 at 18:52, Tim Düsterhus wrote:
> On 8/5/24 14:52, Christoph M. Becker wrote:
>
>> Hmm, so far I only had skimmed the RFC and the related discussions, but
>> now I checked out the suggested implementation[1]. Then I tried to
>> build with PECL/uopz, and of course that failed because
Hi
On 8/5/24 18:06, Levi Morrison wrote:
After thinking about this several times over the course of discussion
and again now that it's in voting, I have decided to vote no. I am in
favor of this change, I just think given the concerns it's best to
wait for PHP 9.0 to do it. Maybe the concerns wi
On 05.08.2024 at 17:42, Pierre Joye wrote:
> On Mon, Aug 5, 2024, 10:03 PM Derick Rethans wrote:
>
>> Instead of having to deal with tickets, wouldn't be be easier if the
>> compiler they used works with the features that we are using? That could
>> instantly provide a link to the documentation s
Hi
On 8/2/24 13:39, Derick Rethans wrote:
It's for that, but also for path/branch analysis, as I just wrote above.
Having an EXIT opcode, instead of a function call is a clean indicator
that a path (and branch) ends here.
With a function call, I have no idea about whether a path ends there.
Hi
On 8/5/24 14:52, Christoph M. Becker wrote:
Hmm, so far I only had skimmed the RFC and the related discussions, but
now I checked out the suggested implementation[1]. Then I tried to
build with PECL/uopz, and of course that failed because ZEND_EXIT is no
longer there. Okay, quickly drop tha
Hi
On 8/5/24 13:04, Derick Rethans wrote:
As userland PHP developer, I always regarded `exit` as a control flow
instruction (quite similar to `break`), and as such I'm not really in
favor of converting it to a proper function (especially since it is
not, because the parantheses could be omitted)
Hi all,
a week ago I've opened a respective ticket on the php-src bugtracker[1]
to ask what is going on with pdo_dblib on Windows. Apparently the
extension is no longer shipped with the official Windows builds for many
years (roughly dropped as of PHP 5.3 or 5.4), and I consider it unlikely
that
On Sun, Aug 4, 2024 at 10:05 AM Gina P. Banyard wrote:
>
>
> On Friday, 2 August 2024 at 14:33, Giovanni Giacobbi
> wrote:
>
> On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo wrote:
>>
>> [...]
>> I started fixing these in a PR [1] which required more changes than
>> expected. After a short discourse
On 05.08.2024 at 16:59, Derick Rethans wrote:
> On Mon, 5 Aug 2024, Christoph M. Becker wrote:
>
>> In my opinion, there is no *need* to enforce this requirement. Just
>> having documentation should be sufficient. Users with an old
>> compilerr will notice issues (i.e. build failures), and even
On Tue, Jul 30, 2024 at 3:52 AM Gina P. Banyard wrote:
>
> Hello Internals,
>
> I have just opened the vote for the "Transform exit() from a language
> construct into a standard function" RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> The vote will last for two weeks until the 13th of Augus
On Mon, Aug 5, 2024, at 6:04 AM, Derick Rethans wrote:
> On Tue, 30 Jul 2024, Christoph M. Becker wrote:
>
>> On 30.07.2024 at 11:49, Gina P. Banyard wrote:
>>
>> > I have just opened the vote for the "Transform exit() from a
>> > language construct into a standard function" RFC:
>> > https://wi
On Mon, Aug 5, 2024, 10:03 PM Derick Rethans wrote:
> Instead of having to deal with tickets, wouldn't be be easier if the
> compiler they used works with the features that we are using? That could
> instantly provide a link to the documentation saving all of us time.
>
it is significantly easi
On Mon, Aug 5, 2024, at 7:27 AM, Vincent de Lau wrote:
> From: Rob Landers
> Sent: Sunday, July 21, 2024 11:21 AM
>
>> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:
>> > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
>> > > Will the alternative syntax on hook not even be put to a
On Mon, Aug 5, 2024, at 8:49 AM, Theodore Brown wrote:
> On Fri, July 26, 2024 at 12:25 Larry Garfield wrote:
>
>> Voting for Asymmetric Visibility is now open.
>>
>> https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> Hi Larry and Ilija,
>
> Thank you for all your work on this RFC!
>
> One part
On Mon, 5 Aug 2024, Christoph M. Becker wrote:
> On 05.08.2024 at 12:49, Derick Rethans wrote:
>
> > On Thu, 1 Aug 2024, Ilija Tovilo wrote:
> >
> >> Hence, it seems like it would be ok to bump our C compiler
> >> requirement to C11. We'd like to make this change before beta 1 if
> >> there are
On Fri, July 26, 2024 at 12:25 Larry Garfield wrote:
> Voting for Asymmetric Visibility is now open.
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2
Hi Larry and Ilija,
Thank you for all your work on this RFC!
One part that doesn't make sense to me is this sentence near the end in the
"R
>
> Consider this example:
>
> namespace Foo;
> echo time();
>
> With my proposal, this would now always call the global time()
> function. You were suggesting that "using local functions" would help
> mitigate this, but I don't think it does.
>
> * The user can't add "using local functions" t
On Mon, Aug 5, 2024 at 1:23 PM Derick Rethans wrote:
>
> On Fri, 2 Aug 2024, Ilija Tovilo wrote:
>
> > As for providing a migration path: One approach might be to introduce
> > an INI setting that performs the function lookup in both local and
> > global scope at run-time, and informs the user abo
On Mon, Aug 5, 2024 at 2:27 PM Nick Lockheart wrote:
>
>
> > I'm not sure your proposal solves the mocking problem. If the engine
> > is to interpret all non-fq calls as global or local, how would a
> > library include your file while switching this configuration, when it
> > is implemented as som
On 05.08.2024 at 13:04, Derick Rethans wrote:
> Xdebug uses exit for exactly that too. For control flow analysis. And I
> also always have considered it to be a control flow instruction.
>
> I see no benefit in changing it to a function, especially because
> there will never be a function "exit" f
> I'm not sure your proposal solves the mocking problem. If the engine
> is to interpret all non-fq calls as global or local, how would a
> library include your file while switching this configuration, when it
> is implemented as some directive in the file?
I'm not sure I understand this questio
From: Rob Landers
Sent: Sunday, July 21, 2024 11:21 AM
> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:
> > On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
> > > Will the alternative syntax on hook not even be put to a vote?
> > It was, a year and a half ago when Aviz was first p
On Mon, 2024-08-05 at 12:27 +0100, Derick Rethans wrote:
> On Sun, 4 Aug 2024, Nick Lockheart wrote:
>
> > https://wiki.php.net/rfc/global_function_parser_directive I am
> > asking
> > that we discuss and vote on the following question:
> >
> > “Should there be some way for developers to signal
On 05.08.2024 at 12:49, Derick Rethans wrote:
> On Thu, 1 Aug 2024, Ilija Tovilo wrote:
>
>> Hence, it seems like it would be ok to bump our C compiler requirement
>> to C11. We'd like to make this change before beta 1 if there are no
>> objections.
>
> How would you enforce that, through configur
On Sun, 4 Aug 2024, Nick Lockheart wrote:
> https://wiki.php.net/rfc/global_function_parser_directive I am asking
> that we discuss and vote on the following question:
>
> “Should there be some way for developers to signal to the parser at
> compile time that all unqualified function names foun
On Fri, 2 Aug 2024, Ilija Tovilo wrote:
> As for providing a migration path: One approach might be to introduce
> an INI setting that performs the function lookup in both local and
> global scope at run-time, and informs the user about the behavioral
> change in the future.
That INI setting wo
On Mon, Aug 5, 2024 at 10:22 AM Nick Lockheart wrote:
>
> > Sorry, my language was not precise enough. Your proposal suggests
> > making unqualified calls global when the directive is present,
> > whereas my proposal suggests keeping local scope as a fallback, hence
> > the two not being compatibl
On Thu, 1 Aug 2024, Ilija Tovilo wrote:
> Hence, it seems like it would be ok to bump our C compiler requirement
> to C11. We'd like to make this change before beta 1 if there are no
> objections.
How would you enforce that, through configure?
FWIW, I have just tried compiling Xdebug with -std
> >
> > I did not intend for all unqualified calls to become global, unless
> > the new directive is present.
>
> Sorry, my language was not precise enough. Your proposal suggests
> making unqualified calls global when the directive is present,
> whereas my proposal suggests keeping local scope
37 matches
Mail list logo
