On Tue, 2024-10-01 at 18:32 -0500, Larry Garfield wrote:
> On Tue, Oct 1, 2024, at 4:02 PM, Nick Lockheart wrote:
> > >
>
> Which is why anyone creating a global namespace class, especially
> with a generic name like that, in 2024 is Doing PHP Wrong(tm).
OK. I'm going
>
> Hey Nick,
>
> Is this actually an issue though? \Directory would be a weird thing
> to autoload. Most people tend to autoload specific namespaces. I
> think it would be weird to autoload into the global namespace.
>
> Maybe I am wrong, and that is why I ask.
>
> — Rob
In a situation where
On Tue, 2024-10-01 at 16:36 +, Gina P. Banyard wrote:
> On Wednesday, 25 September 2024 at 10:12, Nick Lockheart
> wrote:
>
> > On Sat, 2024-09-14 at 15:33 +, Gina P. Banyard wrote:
> > I don't suppose we could call the Directory class something else,
On Sat, 2024-09-14 at 15:33 +, Gina P. Banyard wrote:
> Hello internals,
>
> I came across the Directory class while doing some code exploration
> of ext/standard.
> This class is effectively an opaque object for Directory resources,
> however it doesn't behave like one, as it has existed sinc
>
> 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
>
> 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
> >
> >
> > 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
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
> > > "
>
> 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 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
>
> 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
> 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
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
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
> Currently, PHP strings are binary safe (thus can store any encoding).
> I generally think of PHP strings as being an array of bytes vs. a
> "string" you are familiar with in other languages. The name is
> unfortunate in that regard, but working with them is straightforward
> (imagine having an
>
>
> Some background and history, for those not familiar...
>
> After PHP 5.2, there was a huge effort to move PHP to using Unicode
> internally. It was to be released as PHP 6. Unfortunately, it ran
> into a whole host of problems, among them:
>
> 1. It tried to use UTF-16 internally, as th
HTML 5 was adopted in 2014, over ten years ago. HTML 5 only supports
the UTF-8 multi-byte character encoding.
It seems like there's still a lot of string functions that assume that
a character is a single byte, and these may actually work as expected
when dealing with Latin characters, but may f
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
> 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
> >
> > 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
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
> >
>
> 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,
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
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
>
> 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
> 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
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 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
>
> 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
> 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:
>
> >
> > “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, without a namespace lookup?”
> >
> > Yes: We should do this, let's discuss syntax possibilities.
> >
> > No: This sh
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
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: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 example:
>
> * Per-file, v
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
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
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
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 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 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 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
> > 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.
>
> In regards to hashing, this is likely fine; for now. There still
> isn't an arbitrary pre-image attack on md5 (that I'm aware of). Can
> you create a random file with a matching hash? Yes, in a few seconds,
> on modern hardware. But you cannot yet make it have arbitrary
> contents in our life
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
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 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 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 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
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
50 matches
Mail list logo
