w up RFC is good as is and a low-hanging fruit with high positive
impact, if you ask me.
--
Cheers & thanks,
Nick
Hey internals,
> On 4. Jun 2025, at 20:19, Nick wrote:
>> I believe at the moment that RFC text is all there is. :-) I don't know
>> that it's worth opening a discussion without at least a mostly-done
>> implementation. Also, Ilija is rather busy on other t
not even
> testing that reassigning the property is disallowed, because the test fails
> due to a visibility error. In fact it appears that the `readonly` check comes
> before the visibility check, which would imply that the `readonly` doesn't
> have an effect: https://3v4l.org/nqgpL
You are right. I edited the tests accordingly.
—
Cheers,
Nick
Hey all,
Can someone please grant me RFC edit access?
I’d like to fix two typos in our "Readonly hooks” RFC.
User: nicksdot
Thanks,
Nick
ests/property_hooks/readonly_rfc_example_lazy_product.phpt
NickSdot:readonly-hooks/Zend/tests/property_hooks/readonly_rfc_example_validation.phpt
Thanks for pointing these out!
—
I leave addressing the other points to Larry.
Cheers,
Nick
erface properties cannot be declared readonly today:
>
> https://3v4l.org/cXgR0
>
> Which I think is correct behavior.
Noted, thanks.
> Make sure to include a test based on the "lazy product" example from the RFC
> text. That's the main sort of use case I'd expect we'd want to enable. :-)
Added readonly_lazy.phpt
—
Cheers,
Nick
de for your existing RFC text:
https://github.com/php/php-src/pull/18757
Can it really be such a little change? I’d appreciate feedback from people more
experienced than I am. Thanks!
Cheers,
Nick
Hey Tim,
> On 4. Jun 2025, at 21:09, Tim Düsterhus wrote:
>
> Hi
>
> Am 2025-06-04 14:19, schrieb Nick:
>> Fair. If someone really wants to add random_int(): "well, that assumption
>> doesn't hold anymore, deal” from my side.
>
> Semantically once
ties should allowed for `readonly` properties and in
`readonly` classes.
This would help us to avoid the unnecessary boilerplate like outlined above.
That said, I would greatly appreciate if internals could explore to allow
`readonly` for hooks in promoted properties in 8.5.
--
Cheers & thanks,
Nick
ing now?
Do we keep repeating the same arguments, and disallow bringing this to vote at
all? Even though like literally everyone seems to be on board with “`set` is
ok”?
Or are we allowed to move on with a vote?
> despite there being no clear consensus
The clear consensus seems to be that `set` should be allowed. That’s why we
adjusted the vote.
I repeat: everyone with a problem (any kind) on `get` can vote “no” on `get`
and “yes” on `set`.
—
Again, this is nothing specifically towards Tim.
Cheers,
Nick
> On 20. Jul 2025, at 15:54, Niels Dossche wrote:
>
> On 20/07/2025 02:58, Nick wrote:
>>
>> Hey Niels,
>>
>
> Hey Nick
Hey Nils,
>> The whole controversy is about `get`.
>>
>
> That's true.
> Note though that the fact that th
h against
alternative; PoC):
https://github.com/NickSdot/php-php-src/compare/allow-readonly-hooks...NickSdot:php-php-src:readonly-hooks-strict
Larry and I agree that we don’t want this complexity in the current RFC.
Perhaps this is something for a separate `init` hook RFC?
Cheers,
Nick
(Sorry for the duplicate. I forgot to CC the list)
> On 14. Jul 2025, at 01:15, Eric Norris wrote:
>
> On Sun, Jul 13, 2025 at 2:00 PM Marc Bennewitz wrote:
>>
>>
>> On 13.07.25 18:17, Nick wrote:
>>
>>
>> On 13. Jul 2025, at 20:38, Marc Bennewitz wrote:
>>
>> Hi Nick, Claude,
>
> On 13. Jul 2025, at 20:38, Marc Bennewitz wrote:
> Hi Nick, Claude,
Hey Marc,
> I think it's important to explicitly mark it as "this value will be stored in
> memory", I mean just silently caching the get hook could quickly lead to
> unexpected behavior. Like
Hey Rob,
You asked somewhere for feedback on the syntax conflict.
I would like to propose `Planet::(‘earth’)`.
The double-colon is what we are already used to for factory methods.
Since you called the inline-constructor a “factory function” in the RFC, I feel
it would be a good fit.
Currently, this is a syntax error.
Cheers,
Nick
public readonly int $value {
>> get => $this->value * random_int(1, 100);
>> }
>> ) {}
>> }
>>
>> $unusual = new Unusual(1);
>> var_dump($unusual->value === $unusual->value); // true
>> ```
>>
>> –
> On 11. Jul 2025, at 14:25, Claude Pache wrote:
>
>> Le 11 juil. 2025 à 06:30, Nick a écrit :
>>
>> To not get this buried in individual answers to others:
>>
>> I came up with two alternative implementations which cache the computed
>> `get` h
t;> properties, and that means even readonly classes/properties are
>> >> mutable, in
>> >> the generic case.
>> >
>> > `readonly` guarantees the immutability of identity. While you can
>> > certainly mutate mutable objects, the identity of the store
Hey Rob,
> On 11. Jul 2025, at 01:43, Rob Landers wrote:
>>
>> Nick previously suggested having the get-hook's first return value cached;
>> it would still be subsequently called, so any side effects would still
>> happen (though I don't know why you
public string $some {
set => '' !== $value ? (Output::One === $this->style ?
ucfirst($value) : strtoupper($value)) : throw new \Exception();
}
) {}
}
```
Now that I have proposed alternative implementations with caching, I don’t see
why `get` should not be
Hey all,
> On 8. Jun 2025, at 11:16, Larry Garfield wrote:
>
> As Nick has graciously provided an implementation, we would like to open
> discussion on this very small RFC to allow `readonly` on backed properties
> even if they have a hook defined.
>
> https://wiki.php.n
es. For
instance, for formatting.
In my last answer to Tim I showed an example of what I would expect from
`readonly` properties.
Cheers,
Nick
about the proposed Struct RFC, fwiw. Both care not classes.
So, why not make them more lean than classes, and feel clearly different to
classes?
--
Cheers,
Nick
, I didn’t expect that this RFC will be THAT controversial. 😅
However, I get it. There are good arguments on either side.
I did hope that the “implicit cache” is a decent middle ground, but that also
didn’t work out as I thought.
As mentioned earlier, this is my very first RFC. I am at a point where I am a
bit overwhelmed.
That said, Larry and I heard you and already decided to offer a split vote to
enable us to at least land “set only” in 8.5.
If we didn’t misunderstood it, then y’all agreed on `set` (only) should be
allowed?
This would IMHO already be a huge improvement compared to now; and a low
hanging fruit.
Not exactly what I wanted, but it is what it is.
Long story short. We simply don’t have the time to get `init` sorted before
feature freeze.
I offer to follow up with a “readonly `init` hook” RFC for 8.6 to sort the rest.
I’d appreciate if voters could settle on a yes for “set only” for 8.5.
Wdyt? Would this help to get closer to closing the discussion?
Cheers,
Nick
Hey Rob,
We just discussed your RFCs here. We noticed this in the RFC:
```php
$point1 = &Point(3, 4);
$point2 = $point1; // No data duplication, $point2 references the same data as
$point1
$point3 = Point(3, 4); // No data duplication, it is pointing to the same
memory as $point1
```
Is the `&` on the 3rd line `Point` omitted intentionally or was that just
missed?
If not missed, how is that not ambiguous?
Could you please clarify?
Cheers,
Nick
Hey Niels,
> On 21. Jul 2025, at 15:56, Niels Dossche wrote:
>
> On 21/07/2025 10:29, Nick wrote:
>> @Niels
>> I saw you voted “no” for `set`.
>> I double checked the full RFC discussion. You didn’t participate at all
>> until the very end.
>> Both ma
hat are not the officially documented ones?
Thank you.
Cheers,
Nick
> Improved Readability: Makes the code more concise and focuses on the
> important parts.
>
> Backward Incompatible Changes
>
> None. This is purely an additive change to the syntax.
>
Hey Mihail,
Why would the `catch (SomeError)` still be required if it isn’t used?
Cheers,
Nick
Hi,
Is there any interest in having enums as class constants?
I'm often finding cases where I would like to have an enum inside of a
class, but don't want a free-floating enum that's basically like
another class.
When dealing with state, it's nice to have a human readable const to
represent that
I wanted to reply generally to this and not to any person in
particular, as I'm the one who started the thread.
I used the rather broad title "Should All String Functions Become
Multi-Byte Safe" because there are many smaller related topics, but my
intention was to discuss multi-byte in general, a
> We would upgrade that to a warning in PHP 9.2, and it would end up
> being an error on PHP 10 and have a BC break.
>
> I don't think adding a \ to each function call is ugly, that's what
> we have for classes, and it works fine; or an use statement.
>
> So, why do we think that after people g
>
> BUT, if people already complain about "\" being ugly, having to write
> "namespace\" is going to make them REALLY grumpy...
> So maybe at the same time (or, probably, in advance) we need to come
> up with a nicer syntax for explicitly referencing the current
> namespace.
> Unfortunately, fin
On Fri, 2024-08-23 at 07:39 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 00:15:19 BST, Mike Schinkel
> wrote:
> > Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR
> > PREFERABLE to _\strlen() because at least it provides satiating
> > information rather than the emp
>
> If we were to go with any major change in the current lookup where it
> is perf or nothing, this is what I would propose for php 9.0
> (starting with an immediate deprecation):
> 1. any unqualified call simply calls the current namespace
> 2. >= php 9.0: no fallback to global
> 3. <
On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 23 August 2024 01:42:38 BST, Nick Lockheart
> wrote:
> >
> > >
> > > BUT, if people already complain about "\" being ugly, having to
> > > write
> > > "
> >
> >
> > A third option, which I haven't seen come up on the list yet, is
> > that
> > unqualified functions that are PHP built-ins are treated as global,
> > and
> > using a function having the same name as a built-in, in a namespace
> > scope, requires a fully qualified name to override the
>
> Just like our home page is just boring release announcements. This
> should have much more interesting stuff such as how, and when, to use
> the great new features that we have been adding in the last decade.
>
I would add that there are lots of features where the PHP manual says
how the
>
> What a couple of people have touched on is that that all we have
> right now is a Reference, which is only one kind of documentation.
> The common zeitgeist these days says there's 4: https://diataxis.fr/
>
> * Tutorials
> * How-to guides
> * Explanation
> * Reference
>
> We have a referenc
if i run the CLI through GDB i get this error
when it starts:
This GDB was configured as "i386-linux"...Using host libthread_db
library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Sta
Sorry here is the BT from GDB
(gdb) run
Starting program: /home/nick/Desktop/build-src/php-src/sapi/cli/php
[Thread debugging using libthread_db enabled]
[New Thread 1076758816 (LWP 13474)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076758816 (LWP 13474
Looks like the one. Thanks
Alan Knowles wrote:
Is this the sqlite "build it with gawk" bug?
Regards
Alan
On Wed, 2005-03-30 at 11:09 +1000, Nick Loeve wrote:
Sorry here is the BT from GDB
(gdb) run
Starting program: /home/nick/Desktop/build-src/php-src/sapi/cli/php
[Thread debug
Xuefer wrote:
>
> +1 for "ifsetor"
> but btw, "ifsetor" might be complex for non-englishs. "default" might be
> better.
'default' is a reserved word.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello internals,
I get a segfault when starting apache with debug enabled in the php
build. I am using the latest 5_1 cvs, and apache 1.3
The backtrace i get in gdb is attached.
Is that likely to be caused with memory handling in an extension module?
It works fine in non-debug, but i am just try
hould I open another?
Cheers
--
Nick Loeve
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to the SoapClient class specifically
allows you to say you would like to use exceptions for SoapFaults. Is
this not a SoapFault... ?
>
> On 11/19/07, nick loeve <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I see that the bug was marked fixed in 5.2.5, and that a HTTP
Woops didn't CC the list
-- Forwarded message --
From: nick loeve <[EMAIL PROTECTED]>
Date: Nov 23, 2007 4:21 PM
Subject: Re: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Lukas Kahwe Smith <[EMAIL PROTECTED]>
On Nov 19, 2007 4:45 PM, Lukas Ka
-- Forwarded message --
From: nick loeve <[EMAIL PROTECTED]>
Date: Nov 27, 2007 11:39 AM
Subject: Re: Fwd: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Rob Richards <[EMAIL PROTECTED]>
On Nov 27, 2007 11:33 AM, Rob Richards <[EMAIL PROTECTED]&g
.
Nick Mitin
Borzov-Mitin Solutions, The // http://tbms.ru
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
As another example an extension i maintain will scan a file on upload
using clamav:
http://trickie.org/code/phplibclamav.php
--
Nick Loeve
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I would be inclined to pick the documentation option but it is obviously a
trick question, you should know that finding this form is a trick in itself and
I am making use of this chance/opportunity, if I may.
No this application does not follow the preferred route but please don't
just dismiss
Congrats!!!
--
Nick Wallace
On Thu, Jun 20, 2013 at 4:39 PM, Anthony Ferrara wrote:
> Congrats all!!!
>
>
> On Thu, Jun 20, 2013 at 5:22 PM, Julien Pauli wrote:
>
>> Hello!
>>
>> The PHP Development Team would like to announce the immediate release of
>
Does anyone have any further information on the PECL Binaries for 5.3, will
they be released?
2009/6/30 pan
> Lukas Kahwe Smith wrote:
> >> Hello!
> >>
> >> The PHP Development Team would like to announce the immediate release
> >> of PHP 5.3.0. This release is a major improvement in the 5.X ser
e_imap);
INIT (&st, mail_string, (void *) message, message_len);
-if (mail_append_full(imap_le_struct->imap_stream, folder, (flags ?
flags : NIL), NIL, &st)) {
+if (mail_append_full(imap_le_struct->imap_stream, folder, (flags ?
flags : NIL), (date ? date
Hey Pierre,
No problem. We'll work on a test case and post a bug report when we've created
it.
Thanks,
Nick Fortenberry
-Original Message-
From: "Pierre Joye"
Sent: Tuesday, October 20, 2009 6:13pm
To: "Nick Fortenberry"
Cc: internals@lists.php.net
Sub
to be generous with
whitespace and brackets. Were you referring to something in particular with
regards to whitespace?
Thanks,
Nick
-Original Message-
From: "Jani Taskinen"
Sent: Wednesday, October 21, 2009 2:55am
To: "Nick Fortenberry"
Cc: internals@lists.php.net
Sub
-Original Message-
>From: "Pierre Joye"
>Sent: Wednesday, October 21, 2009 1:54pm
>To: jani.taski...@iki.fi
>Cc: "Nick Fortenberry" , internals@lists.php.net, "Jake
>Levitt" >
>Subject: Re: [PHP-DEV] Patch: Add INTERNALDATE to ima
to a single e-mail address.
*
* @param string $email An e-mail address.
*/
/[ EmailValidation(array('options' => array('checkMX' => true)) ]/
public function sendEmail($email) { ... }
}
Anyway. Just some thoughts.
Cheers,
Nick
On 12/09/10 09:30, Chr
On 25/11/10 07:41, Lester Caine wrote:
Patrick ALLAERT wrote:
2010/11/25 Lester Caine:
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that
the git
cygwin install destroys! And as yet there is no consensus on getting it
worki
On 25/11/10 10:14, Lester Caine wrote:
Nick Pope wrote:
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breaka
On 25/11/10 11:47, Lester Caine wrote:
Nick Pope wrote:
I really couldn't make sense of this. Also - did you actually read my
last reply? The link I sent you linked to this:
http://www.eclipse.org/egit/
I've never used it. I can't vouch for it. But if that isn't some fo
On 25/11/10 12:22, Pierre Joye wrote:
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caine wrote:
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no solution,
while simply un-installing it restored all of the broke
, there could also be getMaxLineLength(). This would need
a different name however as this method would be to count the longest
line of the file rather than indicate the maximum length of a line to
read as the current SplFileObject::getMaxLineLen() method does.
Just my thoughts,
Nick
On 14/03
hasTrailingWhiteSpace()
...
It may also make sense to cache the result while the file is not
modified as some of these operations could be expensive.
Anyway - I'll stop rambling. I think this would be better than just
hacking in a method for the sake of it.
Cheers,
Nick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
property (exact type match only)
- interface properties must be public
- interface properties can't be static
- interface properties can be readonly
Open to feedback from everyone on this - keen to get the ball rolling quickly
on it!
Kind Regards,
Nick
--
PHP Internals - PHP Runtime De
be in PHP is
> necessarily relevant to whether or not one supports this proposal, though.
Agreed, I think the key question for this RFC to progress is "Should an OOP
language interface support public properties".
- Nick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi Internals,
As per my earlier post discussing the concept of an RFC to add public
properties to interfaces, I would like to request karma to create this RFC.
Thanks,
Nick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> The folks handing out the RFC karma would need to know your Wiki
> username to do so.
Thanks Tim, apologies for not including it in the original request.
Username is "humni"
Thanks,
Nick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
What is the general feeling about reserving a namespace for PHP's built
in classes?
As the number of built-in classes grows over time, the chances of
naming collisions with user classes will grow.
When naming conflicts occur, they happen in an unexpected way, that
does not make it readily obvio
On Wed, 2024-07-24 at 19:51 +0200, Tim Düsterhus wrote:
> Hi
>
> On 7/24/24 19:43, Nick Lockheart wrote:
> > What is the general feeling about reserving a namespace for PHP's
> > built
> > in classes?
>
> see https://wiki.php.net/rfc/namespaces_in_bund
On Wed, 2024-07-24 at 22:02 +0200, Tim Düsterhus wrote:
>
> > I think a better solution would be to have one namespace for all
> > bundled classes, so that a specific namespace is reserved in
> > advance.
>
> Needing to prefix everything by \PHP or something like this would
> provide for a terri
On Thu, 2024-07-25 at 17:33 +0200, Tim Düsterhus wrote:
>
> As an example, using md5_file() to implement a cache buster is fine,
> but a less-experienced developer may believe that md5_file() uniquely
> identifies the file contents and use it in a way where strong
> collision-resistance against a
On Thu, 2024-07-25 at 22:34 +0100, Rowan Tommins [IMSoP] wrote:
> On 24/07/2024 23:01, Morgan wrote:
> > And they would still be available as hash("md5") and hash("sha1");
> > the
> > only reason they're called out as their own distinct functions
> > today
> > is historical inertia.
>
>
> I do
On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer wrote:
> On 26-7-2024 0:00, Nick Lockheart wrote:
>
> >
> > That's a good point. What if there were crypto functions that
> > worked
> > like password_hash() in that they had one generic function n
a websever/host updates the PHP version and the code breaks, the
last thing a dev is looking for is "what's the best practice to
refactor this code".
The dev is thinking, "our site is down, the boss/client is angry,
what's the fastest band-aid I can slap on this to get the site up
again".
Thus:
Provide tools, not policy.
Provide good documentation.
--
Nick
> > I think a better solution would be to have one namespace for all
> > bundled classes, so that a specific namespace is reserved in
> > advance.
>
> Needing to prefix everything by \PHP or something like this would
> provide for a terrible developer experience when using the standard
> library.
On Sun, 2024-07-28 at 00:48 +0200, Claude Pache wrote:
>
> For the case of functions (and constants) in the global namespace,
> there was an RFC on the subject about 4 years ago, which has been
> declined; see: https://wiki.php.net/rfc/use_global_elements and the
> discussion threads referenced
> On Sun, 2024-07-28 at 00:48 +0200, Claude Pache wrote:
> >
> > For the case of functions (and constants) in the global namespace,
> > there was an RFC on the subject about 4 years ago, which has been
> > declined; see: https://wiki.php.net/rfc/use_global_elements and the
> > discussion threads r
On Fri, 2024-08-02 at 18:51 +0200, Ilija Tovilo wrote:
> Hi everyone
>
> As you probably know, a common performance optimization in PHP is to
> prefix global function calls in namespaced code with a `\`. In
> namespaced code, relative function calls (meaning, not prefixed with
> `\`, not imported
On Fri, 2024-08-02 at 18:53 +0100, Rowan Tommins [IMSoP] wrote:
>
>
> On 2 August 2024 18:19:41 BST, Nick Lockheart
> wrote:
> > I had suggested a per-file directive in a post to this list a while
> > back. Something like:
> >
> > namespace foo;
> &
On Fri, 2024-08-02 at 21:37 +0100, Bilge wrote:
> Hi Ilija,
> I think this proposal has legs, and you are right to rekindle it,
> instead of letting it die quietly.
> On 02/08/2024 17:51, Ilija Tovilo wrote:
>
> > * Some mocking libraries (e.g. Symfony's ClockMock [5])
> > intentionally
> > decla
Good morning,
I am writing to request RFC karma for the wiki account with username
`nlockheart`.
I would like to write an RFC for community discussion and
consideration.
Thank you,
Nick Lockheart
Good morning all:
When calling functions from the *global* namespace, the PHP parser
creates opcodes that use those functions directly. When those functions
are certain built-in functions, the parser can use special opcodes that
are optimized for those function calls.
When calling functions from
Good morning all:
When calling functions from the *global* namespace, the PHP parser
creates opcodes that use those functions directly. When those functions
are certain built-in functions, the parser can use special opcodes that
are optimized for those function calls.
When calling functions from
On Sun, 2024-08-04 at 19:15 +0200, Ilija Tovilo wrote:
> Hi Nick
>
> I find it a bit unfortunate that you gave my thread barely any time
> to
> be discussed.
>
My intent was to start a formal discussion on this very topic.
> This can be achieved in various ways. For exa
On Sun, 2024-08-04 at 20:02 +0200, Christoph M. Becker wrote:
> On 04.08.2024 at 15:09, 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
On Sun, 2024-08-04 at 19:53 +0200, Ilija Tovilo wrote:
> Hi Claude
>
> On Fri, Aug 2, 2024 at 9:02 PM Claude Pache
> wrote:
> >
> > I propose the following alternative approach:
> >
> > * establish a restricted whitelist of global functions for which
> > the performance gain would be noteworthy
discuss syntax possibilities.
> >
> > No: This should not be a feature at all.
> >
> > Thank you for your consideration.
>
> Hi Nick
>
> I'm not sure how I feel about adding an additional signaling / syntax
> system
> to signal the parser to change th
> My thought was that it would have some clean and simple syntax, like:
>
> namespace foo using global functions;
> class MyClass{
>
> }
>
> When the parser hits that token, it just sets a flag and acts like
> every unqualified classname has a backslash in front of it.
>
> For everyone else:
>
>
> But that's not quite what the RFC says:
>
> > 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 found in a
> > namespace context are global, withou
> >
> > 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
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
> 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
>
> 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
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
Sandbox: Security
A SandBox has two use cases:
1. Unit Testing of code with mocks or stubs, and also, allowing testing
with different environments.
2. The secure running of 3rd party code inside a 1st party application.
For the second use case, I will use a fictional blogging software
called
>
> This looks quite valuable, and I assume auto loading would work just
> like normal? Register an autoloader that will eventually require the
> file and call this function?
>
> It would be nice to provide a simplified api as well, maybe
> “CopyCurrentEnvironment()” or something? In most cases,
On Tue, 2024-08-06 at 20:51 +0200, Rob Landers wrote:
> Hey Nick,
>
> Looking forward to the RFC!
>
> On Tue, Aug 6, 2024, at 19:28, Nick Lockheart wrote:
> > >
> > > This looks quite valuable, and I assume auto loading would work
> > > just
> >
> >
> > Introducing a sandbox API for security also opens up a can of worms
> > for the security policy. Right now we are assuming an attacker
> > model of a remote attacker, and that the code running on your
> > server is trusted. But that would change when an official sandbox
> > API is introd
> Voting has now concluded for static class. The first vote cast was
> for, and of the first four votes cast, three were for and one was
> against. As the votes continued to roll in, however, it was clear
> which direction the wind was blowing. The final tally reached the the
> 2/3 critical mass
On Sat, 2024-08-10 at 23:37 +0100, Bilge wrote:
> On 10/08/2024 23:32, Nick Lockheart wrote:
> > > Voting has now concluded for static class. The first vote cast
> > > was
> > > for, and of the first four votes cast, three were for and one was
> > > aga
1 - 100 of 118 matches
Mail list logo
