Re: [PHP-DEV] Module or Class Visibility, Season 2

On Mon, Jun 2, 2025 at 10:40 PM Larry Garfield wrote: > On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote: > > On 02/06/2025 17:57, Larry Garfield wrote: > >> Well, now you're talking about something with a totally separate > compile step, which is not what Michael seemed to be describ

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Sun, Jun 1, 2025 at 3:18 AM Rob Landers wrote: > This could work! I have a couple of critiques, but they aren’t negative: > > I think I like it. It might be worth pointing out that JavaScript "hoists" > the imports to file-level during compilation — even if you have the import > statement buri

Re: [PHP-DEV] Module or Class Visibility, Season 2

Ok, the conversation is getting sidetracked, but I think some progress is being made. I started this latest iteration last year with a thread about introducing something similar to the ES module system of JavaScript to PHP. What attracts me to this particular model is that it should already be fam

Re: [PHP-DEV] Re: PHP True Async RFC Stage 3

On Wed, May 28, 2025 at 2:01 PM carlos_silva wrote: > Hello everyone. > > I've been thinking about core developers these days, and I'm happy to see > the PHP foundation growing, and more and more new developers arriving, > eager to push PHP forward. > > But at the same time, I have the feelin

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Thu, May 22, 2025 at 4:29 PM Rowan Tommins [IMSoP] wrote: > On 22/05/2025 12:09, Michael Morris wrote: > > >> I've tried several times to explain why I think Linux containers are a >> good analogy; I'm not sure if you didn't understand, or just didn't

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Wed, May 21, 2025 at 8:27 AM Rowan Tommins [IMSoP] wrote: > > So if we can come up with a solution where only the WordPress plugins need > to be changed, and you can use whatever dependencies you want without > waiting for them to be changed to a new way of working, is that not a good > thing?

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Wed, May 21, 2025 at 7:23 AM Deleu wrote: > > > On Tue, May 20, 2025 at 11:08 AM Michael Morris > wrote: > >> The Problem: Interoperability. >> >> That's really it. >> > > I think this is why Rowan keeps telling you to call or compare this wi

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Tue, May 20, 2025 at 6:18 PM Rowan Tommins [IMSoP] wrote: > > > On 20 May 2025 15:04:49 BST, Michael Morris wrote: > >The Problem: Interoperability. > > > >That's really it. Scenario > >Alice provides whatchamacallit A that depends on other whatchama

Re: [PHP-DEV] Module or Class Visibility, Season 2

The Problem: Interoperability. That's really it. Scenario Alice provides whatchamacallit A that depends on other whatchamacallit D to work. Bob provides whatchamacallit B that also depends on D. Charles is using A and B. D gets updated with a new incompatible API to its prior version. Alice publi

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Wed, May 14, 2025 at 10:57 AM Rowan Tommins [IMSoP] wrote: > > I don't know much about Go, but at a glance it uses a similar model to > JavaScript and Python where *classes don't have a universal name*, the > names are always local. That's not a different kind of module, it's a > fundamentally

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Wed, May 14, 2025 at 4:08 AM Rowan Tommins [IMSoP] wrote: > > What Michael Morris is talking about is really a completely different > concept - it's more like "containers", in the sense of Docker, Kubernetes, > etc, where different sections of code can be isolated,

Re: [PHP-DEV] Module or Class Visibility, Season 2

On Tue, May 13, 2025 at 11:31 AM Deleu wrote: > Hi! > > This would allow public, private and protected classes in a way that I > believe to be useful for the large ecosystem that surrounds Composer. From > my extremely limited understanding of the engine, I think the easy/natural > step would be

Re: [PHP-DEV] [Vote] Pipe operator

Thank you for your work on this. While I will enjoy this feature if it passes, it irks and saddens me that... once\again::PHP->has|>added a.feature.other.languages.only.need.dot.for That isn't your fault, and any hope of changing that about the language left the station decades ago. On Mon, May

Re: [PHP-DEV] Modules, again.

On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP] wrote: > > Problem number 2 is what you seem to be trying to address. > The main thing, yes. This solution incidentally solves class privacy issues several unrelated and failed RFC's have addressed, including Nested Classes which is currently

Re: [PHP-DEV] Modules, again.

On Wed, May 7, 2025 at 10:59 AM Larry Garfield wrote: > > So it's not really giving private symbols. It's not even blocking access > to anything, since it can still just be included or autoloaded. What > you're proposing is really just an optional loading facade (the real kind > of facade) that

Re: [PHP-DEV] Modules, again.

Resetting and moving the proposal writeup to a github hosted markdown file here: https://github.com/michael-lloyd-morris/php-modules-rfc/blob/main/php-modules.md On Mon, May 5, 2025 at 12:44 AM Larry Garfield wrote: > > > So before you get indignant and call me a liar ("You're 4 for 4 on > false

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 5:38 PM Larry Garfield wrote: > > > PHP Code > --- > > > > namespace MyModule; > > > > yield function sum(a, b) { return a + b; } > > > > > --

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 5:19 PM Larry Garfield wrote: > On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: > > It's been 9 months. Been researching, working on other projects, > > mulling over > > points raised the last time I brought this up. And at the moment I &

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 7:06 AM Arvids Godjuks wrote: > > It ended exactly how my first judging brain wave thought it would go - > this whole thing is about fixing WordPress by changing the language. Plain > and simple. > > That is a lie. Go back and read again - I discuss how this will improve Dr

[PHP-DEV] Modules, again.

It's been 9 months. Been researching, working on other projects, mulling over points raised the last time I brought this up. And at the moment I don't think PHP 8.5 is in its final weeks so this isn't a distraction for that. The previous discussion got seriously, seriously derailed and I got lost

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Wed, Jul 10, 2024 at 3:29 PM Rowan Tommins [IMSoP] wrote: > > > On 10 July 2024 19:08:39 BST, Michael Morris wrote: > > Just to repeat a point that's been raised a few times: this is not a great > time of year for this kind of discussion. If you come back after 8.4

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Wed, Jul 10, 2024 at 5:51 AM Jordi Boggiano wrote: > > As for the rest of the thread, I feel like everyone needs to take a few > days to chill because it's getting a bit heated around here. > People are passionate about the things they love. I've been busy with work and on Iteration V. Detai

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Sat, Jul 6, 2024 at 2:12 AM Mike Schinkel wrote: > On Jul 5, 2024, at 1:47 PM, Michael Morris wrote: > I went to sleep thinking about this post, on import maps in general and > how Composer works, specifically when you use a class map instead of the > PSR-0 or PSR-4 schemes.

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Fri, Jul 5, 2024 at 2:23 PM Dusk wrote: > > To that end - consider the following. Let's say that two different files > in your project import different versions of package Foo. Foo contains a > definition of the FooBar class, and contains functions which return that > object. > > 1) If $foobar

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Fri, Jul 5, 2024 at 1:29 AM Mike Schinkel wrote: > On Jul 4, 2024, at 9:16 PM, Michael Morris wrote: > On Wed, Jul 3, 2024 at 11:11 PM Mike Schinkel wrote: > >> So I've had more time to mull this over, and some research, and I think I >> have an approach. >

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Wed, Jul 3, 2024 at 11:11 PM Mike Schinkel wrote: > >> import 'file.php v1.0.0'; > > > > Where will PHP be able to get the version number in a performant manner? > > > > A question for another day. > > Frankly if your proposal hinges on using version numbers to differentiate > then I think i

Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

On Wed, Jul 3, 2024 at 9:56 PM Mike Schinkel wrote: > > There are ~6300 uses of the keyword `import` on GitHub: > > > https://github.com/search?q=import+language%3APHP+symbol%3A%2F%5Eimport%24%2F&type=code > > > That'

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Wed, Jul 3, 2024 at 7:52 PM Mike Schinkel wrote: > Me personally, the opinions that I do not like are the one-symbol-per file > assumption, which is also a key issue I have with PSR-4. > That's a PSR-4 issue, not an autoloader one. Autoloaders, even in composer, can use class maps to discover

[PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)

Hello all. Hitting reset again as the primary problem at hand has become clear. Let's recap it. Autoloading is great for loading packages, but it can't load different versions of the same package at the same time. Why would you want to do that? When you don't have full control of the code. For

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Wed, Jul 3, 2024 at 1:24 PM Rob Landers wrote: > > So, if v4 has BC breaks ... how would Drupal not crash? If you allow > multiple versions, how would you use both versions? I'm not even sure that > is a logical possibility. > > Twig in Drupal will be installed the old way and find itself boun

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Wed, Jul 3, 2024 at 12:52 PM Matthew Weier O'Phinney < mweierophin...@gmail.com> wrote: > > > I'm following the packaging threads closely, and the one thing I've failed > to see a solid argument for is _what problems_ the current approach of > using namespaced code doesn't address. > Running m

Re: [PHP-DEV] Packages Iteration 3: was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Mon, Jul 1, 2024 at 1:33 AM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Michael, > > pon., 1 lip 2024 o 01:18 Michael Morris napisał(a): > >> ... >> Applications >> >> The application is the root package. It is the package t

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Wed, Jul 3, 2024 at 7:49 AM Aleksander Machniak wrote: > On 3.07.2024 07:32, Richard Miles wrote: > > What if php implicitly prepended namespaces with the composer package > version? > > If two incompatible versions are required, the composer downloads both. > Enabled/Disabled with flag? > > W

Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

On Mon, Jul 1, 2024 at 9:02 AM Larry Garfield wrote: > 2. Supporting multiple versions of the same class is *wy* out of > scope. No, it's actually the heart of the problem now that I've had a few days to think on this, and it's something an autoloader can NOT resolve. > You seem to imply

[PHP-DEV] Packages Iteration 3: was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

First off, in 10 years of using gmail I've never had it lose an email. Well, it happened after I spent 4 hours on this. So, this is sorta iteration 4. I'll type this up in Visual Studio code and then paste to gmail. The Wordpress discussion about composer and the decision not to use it keys in t

[PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)

So let's take another crack at this based on all the points raised in the thread. This should also underline why I don't consider this an RFC - I am iterating until we arrive at something that may be refinable into an RFC. And I say we because without the aid of those in this conversation I would n

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

I have no proposal. I'm brainstorming. Please don't step out of this conversation as it has been enormously helpful. On Sun, Jun 30, 2024 at 2:48 AM Mike Schinkel wrote: > > On Jun 29, 2024, at 10:57 AM, Michael Morris wrote: > > On Sat, Jun 29, 2024 at 5:40 AM

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 2:20 PM David Gebler wrote: > On Thu, Jun 27, 2024 at 4:33 AM Michael Morris wrote: > >> Hello all. This is a ramble of an idea that's managed to run around my >> head for a few days now. It isn't fully formed, but I've ran the thought &g

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 7:15 AM Rob Landers wrote: > > With a bit of finangling, you can actually port JavaScript line-for-line > to PHP, but not the other way around. > JavaScript uses prototypical inheritance, and any program that leverages that aspect of it will be IMPOSSIBLE to port to PHP l

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 5:43 AM Mike Schinkel wrote: > > On Jun 28, 2024, at 10:12 AM, Rowan Tommins [IMSoP] > wrote: > > > Also, the JS insistence on having a separate package for every tiny > function is a common source of criticism, so personally I am very happy > that PHP packages are genera

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 5:40 AM Mike Schinkel wrote: > However, be aware that in a Go project repo you are likely to have only > one `go.mod` — or multiple if you have numerous CLI apps being generated — > whereas every directory with Go code is a package (which I think is > equivalent to what yo

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 3:52 AM Rob Landers wrote: > I don't think that is correct... > Correct or not it's irrelevant trivia. While this looks good on paper, you're going to have to standardize how > packages are accessed (API calls, etc) so they can be used in this file, or > literally anyone

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

Not replying to anyone in particular and instead doing a mild reset taking into account the discussion that has gone before. So, I want to import a package. I'll create an index.php file at the root of my website and populate it with this. 'Hello {{ name }}' ]); $twig = new Environment($loader

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

ng needs to be > contemplated in the design. PHP has to be able to know what is a module and > what isn't without expensive processes. > One possible solution is that if modules do not have tags, ever, and someone directly tries to load a module through http(s) the file won't exe

Re: Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 4:55 PM Rob Landers wrote: > On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote: > > > On Thu, Jun 27, 2024 at 1:02 PM MKS Archive > wrote: > > > Interesting to see this. Serendipitous given the email I sent on the list > in reply to Lar

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 3:52 PM Jim Winstead wrote: > On Wed, Jun 26, 2024, at 7:15 PM, Michael Morris wrote: > > PHP User Modules are php files that are brought into the runtime through a > new parser that is able to generate faster and more concise runtime code by > remov

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 1:02 PM MKS Archive wrote: > > Interesting to see this. Serendipitous given the email I sent on the list > in reply to Larry. > > My initial thoughts: > > 1. I really like the concept of cleaning up issues that BC make impossible > to fix by introducing modules. > Thanks.

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 2:11 PM Deleu wrote: > Who would build it is an extremely key aspect of making changes to PHP. > Ideas are hard enough to survive the RFC process when there's already an > implementation. Finding a sponsor to work on this would be the first step. > Agreed. > > Given tha

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 2:29 PM Jordan LeDoux wrote: > > > On Thu, Jun 27, 2024 at 11:13 AM Deleu wrote: > >> Who would build it is an extremely key aspect of making changes to PHP. >> Ideas are hard enough to survive the RFC process when there's already an >> implementation. Finding a sponsor t

[PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

Hello all. This is a ramble of an idea that's managed to run around my head for a few days now. It isn't fully formed, but I've ran the thought experiment as far as I can on my own and want to share it with all of you. I've mostly been a lurker and I've seen a lot of RFC's come and go. Of those no

[PHP-DEV] PHP Modules

This will be long. I've read over the Future Stability thread and taken it in, and decided to mull over an idea I touched on over a decade ago that I think might help. Also, in the interceding years the JavaScript community has overcome a compatibility issue using this technique, so we might do the

Re: [PHP-DEV] Re: Removal of ${} string interpolation in PHP 9

I can understand removing this feature since it is a bit confusing, but are there any plans to replace it - say with the template literal syntax of JavaScript? For those needing to refactor having something to switch to would be preferable than having the feature dropped. Or does PHP have some goo

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Wed, Mar 2, 2022 at 3:31 AM Victor Bolshov wrote: > Hello internals. > > In these dark days for humanity, we as people of civilization, people > of sanity, kind and caring people with children and families - we have > to speak up, loud and clear, in support for Ukraine. To stop Russian > aggre

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

On Mon, Jan 10, 2022 at 8:05 AM Tim Düsterhus, WoltLab GmbH < duester...@woltlab.com> wrote: > Hi Internals! > > this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th. > > Christoph Becker granted me RFC editing permissions and I've now written > up our proposal as a proper RFC

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov wrote: > > >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins < > rowan.coll...@gmail.com>: > > > >On 31/12/2021 00:21, Kirill Nesmeyanov wrote: > >> I support this behavior fix because in its current form, due to a > similar problem (almost?)

Re: [PHP-DEV] Could we drop the bottom-posting rule?

If this list has ever had a "bike shed" issue, this would be it. https://en.wikipedia.org/wiki/Law_of_triviality On Tue, May 11, 2021 at 10:01 AM Mel Dafert wrote: > >> This plaintext reply sent via Gmail web client. I don't know what Mel is > >> talking about either. > >> > >> > >Gmail's web

Re: [PHP-DEV] Inline conditional that returns null if falsy

Javascript has this now though support isn't widespread. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining The most similar way to do it in PHP would be ?-> On Fri, Feb 12, 2021 at 1:46 PM Ben Ramsey wrote: > > The => is just a suggestion, other opti

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

I so rarely post to the list that when I got this tripe I figured the problem had to be pretty widespread which is why I posted a reply to the list. On Thu, Jan 14, 2021 at 3:05 PM Stanislav Malyshev wrote: > Hi! > > > He's also apparently has been emailing people individually off-list > > accor

Re: [PHP-DEV] silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

t the moderators issue a ban to you, and I will be blocking your email address. On Sun, Jan 10, 2021, 9:30 AM Reindl Harald (privat) wrote: > > > Am 10.01.21 um 16:11 schrieb Michael Morris: > > Owning and managing the silicon directly isn't > > advised anymore and hasn&

Re: [PHP-DEV] silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

The most secure setup possible is to use a static site generator and upload it's output to a static server with no server side parsing enabled. In my opinion Hugo is the best of these which is written in Go, and that's it's largest drawback - written in a language I'm not too familiar with. Jigsaw

Re: [PHP-DEV] Namespace-private class properties

This sort of thing would be useful. Drupal and Symfony both mark methods in their libraries that aren't supposed to be used externally, but people do anyway and then they get mad at the framework developers when they decide to rearrange what are supposed to be internal methods. I wrote a userland

Re: [PHP-DEV] Proposal: php.ini environment variable fallback value

On Mon, Jul 27, 2020 at 12:18 AM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Michael, > > niedz., 26 lip 2020, 06:22 użytkownik Michael Morris > napisał: > >> PHP's ini values are already a bit of a mess. You have a global php.in

Re: [PHP-DEV] Proposal: php.ini environment variable fallback value

PHP's ini values are already a bit of a mess. You have a global php.ini file, and then most PHP ini directives can be set per directory using the .htaccess file. About a third can be set at runtime. This makes tracking down where a setting came from a bit of a headache unless care is taken. This

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

What other language allows this? None that I can think of. Do we want PHP doing something it's most closely related languages do not allow? Why don't they allow this? What problems are we creating by allowing this? I can imagine this would make autoloading functions and constants by namespace more

Re: [PHP-DEV] RFC: separate inheritance from subtyping (PHP v8)

PHP's notion of "implements" is identical to that of Java and C#. This is not by accident, many programmers have to work in multiple programming languages. The less a language does things "differently" the better. And honestly, the upsides of this proposal are not worth the BC breaks created with

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

On Sat, Apr 25, 2020 at 3:28 AM Rowan Tommins wrote: > Hi Michael, > > On 25 April 2020 00:00:32 BST, Michael Morris wrote: > >Changing function names and argument orders would lead to BC breaks so > >massive people would move away without a transition plan that was >

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

On Fri, Apr 24, 2020 at 6:09 PM Mark Randall wrote: > On 25/04/2020 00:00, Michael Morris wrote: > > So, in steps: > > > > 1. Take the current function roster - all of it - and put it in > > \PHP\Legacy\. So the formal name of strpos would become > > \P

Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy

On Thu, Apr 23, 2020 at 9:48 AM Mark Randall wrote: > On 15/04/2020 12:21, Mark Randall wrote: > > https://wiki.php.net/rfc/php_namespace_policy > > Just an update in light of the two different RFCs. > > Having chatted with the other RFC authors in R11, rather than racing to > see who can get the

[PHP-DEV] Thoughts on adopting Python's for/foreach else construct.

I don't remember if this has been discussed before, but I've been working with some listing code and wishing for a cleaner way to do this $value) { // code for iteration } } ?> How difficult would it be to make the following work in the interpreter? $value) { // code for iterat

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

The replies so far have been excellent and I do appreciate the time given to write them. Being a lazy one-language American (I tried to learn Spanish but I've forgotten most of what I learned out of lack of use) I'm not familiar with the obstacles to learning English beyond "gittin rid my accint" w

[PHP-DEV][DISCUSSION] Multilingual PHP

Submitted to the floor is a Wired article from 2 days ago I came across https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/ The manual of PHP is translated into multiple languages - but what are the development hurdles of the language itself being multilingual? >From

Re: [PHP-DEV] Unifying logical operators

On Mon, Jul 9, 2018 at 10:03 PM Ryan wrote: > Hello all! Longtime PHP user, first-time contributor to internals (sorry > if I screw anything up)! > > I'd like to propose either the deprecation (7.next - likely 7.4 at this > point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and),

Re: [PHP-DEV] PHP 8 next?

On Mon, Jun 25, 2018 at 2:55 PM Zeev Suraski wrote: > On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler > wrote: > > > 1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 > was > > released, because we had already made major updates to upgrade to 7.0, > and > > 7.1 introduced a few

Re: [PHP-DEV] PHP 8 next?

On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder wrote: > On 06/23/2018 03:11 PM, Zeev Suraski wrote: > > > > > >> -Original Message- > >> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > >> Golemon > >> Sent: Sunday, June 24, 2018 1:07 AM > >> To: Nikita Popov > >> Cc: P

Re: [PHP-DEV] Better types without runtime checking

On Tue, Jun 5, 2018 at 2:22 AM Rudolph Gottesheim wrote: > There's always a lot of talk about types in the PHP community. > Specifically, many developers want property types, generics, function > signature types, union and intersection types, and more. Those talks > (and RFCs) always end with the

Re: [PHP-DEV] About assert()

d. On Wed, Feb 14, 2018 at 7:43 AM, Pedro Lacerda wrote: > The same beharviour, but `assert` as statement also uses 1 character less. > > > Em 14 de fev de 2018 10:13 AM, "Michael Morris" > escreveu: > > > On Wed, Feb 14, 2018 at 1:16 AM Pedro Lacerda wrote: &

Re: [PHP-DEV] About assert()

On Wed, Feb 14, 2018 at 1:16 AM Pedro Lacerda wrote: > Hi developers, > > Trying to resolve the bug #75950 (that after long hours I found that I > couldn't reproduce), I observed that if `zend.assertions >= 0` the > generated code inside `assert()` was indeed executed even if `assert.active > = o

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

On Mon, Feb 12, 2018 at 1:43 PM, Wes wrote: > Again, the reason is: in case in future PHP wants to use backticks for > unicode strings, like javascript. > If the community think it's feasible, in PHP 9, 10, whatever, it must be > deprecated asap. > If you think PHP should use a different syntax f

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

On Mon, Feb 12, 2018 at 8:38 AM, Eli White wrote: > I'll chime in on the "What evidence do you have that this is not > widely-used" ... in fact, I have seen through my PHP career this used very > regularly, and training/workshop/class sessions at conferences still > regularly teach this as the 's

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

On Sun, Feb 11, 2018 at 1:41 PM, Wes wrote: > Hello PHPeople, I present to you... the shortest RFC ever. > > https://wiki.php.net/rfc/deprecate-backtick-operator > > Let me know what you think! > -1, not that my vote matters, but huge -1. Nothing of value is gained by doing this. If there is so

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

:07 GMT+00:00, Michael Morris > wrote: > >I'm fine with this - I just want the inspector to be part of the > >language > >so that a hidden dependency isn't required. > > I may be being dumb, but I don't get why you keep referring to this as a > "hid

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Tue, Jan 30, 2018 at 2:24 PM, Levi Morrison wrote: > On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield > wrote: > > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote: > >> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield > > >> > >> wrot

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta wrote: > > On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris wrote: > >> The problem is that behavior has been around so long that any attempt to >> change it would incur a massive amount of changes. Using the E_STRICT >&

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

May I propose a compromise? If I understand what I've read over, the default of functions and constants to global scope is the primary blocking issue for creating an autoloader for these elements. Where that not PHP's behavior this functionality could have been implemented by now. The problem is

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Tue, Jan 30, 2018 at 12:13 PM, Larry Garfield wrote: > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote: > > On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield > > > > wrote: > > > Really, these functions would be useful only on arrays, period.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield wrote: > > > Really, these functions would be useful only on arrays, period. To allow > them > on anything else is just dangerous, and on other iterables there are > better, > more robust approaches (as discussed elsewhere in this thread). > > As yo

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins wrote: > On 29 January 2018 19:14:43 GMT+00:00, Michael Morris > wrote: > > The is_callable() > >above prevents iteration over generators, potentially consuming them > >for no purpose. > > Unfortunately, it d

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins wrote: > > Nor are generators the only non-rewindable iterables you need to worry > about, so really the only options you have are to only inspect arrays, or > to add a big fat warning that the function may consume your iterable (or > enter an infini

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

> The more angles we approach this, the more it looks like generics, or at > least the same basis. Which is well outside the scope of what I'd like to see, so let's look at form 2 in closer detail - the all functions. bool all_array( mixed $var ) { if (is_iterable($var) && !is_callable) {

Re: [PHP-DEV] Shorthand proposal for associative arrays

Forgot something in the previous post... On Fri, Jan 26, 2018 at 12:16 PM, Christian Schneider wrote: > Hi there, > I have a proposal for a shorthand notation of associative arrays borrowed > from another language: > :$foo > would be equivalent to > 'foo' => $foo > and would work

Re: [PHP-DEV] Shorthand proposal for associative arrays

On Fri, Jan 26, 2018 at 2:00 PM, David Rodrigues wrote: > Maybe you should see the extract() method. Uhm, what? You need to learn what extract does before you recommend it as an alternative to someone's proposal. Extract takes an array and moves their keys onto the local symbol table. So extr

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller wrote: > Michael Morris schrieb am Fr., 26. Jan. 2018, 02:06: > >> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller wrote: >> >> > >> >> >> >> $a instanceof array >> >> >>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller wrote: > >> >> $a instanceof array >> > > That might work, but array should only return true if it's an > array, not for anything that implements ArrayAccess. > > Related: On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison wrote: > > > I see no value

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller wrote: > > So, given `$a collectionof string` the operator returns whether or not $a >> is, at that time, a collection of strings (be it an array or other >> iterable). It doesn't insure $a will stay that way - it's just a check of >> the variables s

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 2:16 PM, Rowan Collins wrote: > On 25/01/2018 18:56, Michael Morris wrote: > >> Ok, let's stay on topic please. >> This RFC discussion is about an operator or family of functions to verify >> that a given $var is a collection. Obj

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins wrote: > On 25/01/2018 14:52, Derick Rethans wrote: > >> IMO, it makes a lot more sense to check integrity when creating the >> "array" structure. Instead, I would suggest to add a native Collection >> type, that takes a "type" as argument. They aren

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 10:14 AM, Bishop Bettini wrote: > > Agreed, and we can get *almost* there today with: > > $collection = collection_of('is_int', [ 1, 2 ]); > Ok, let's stay on topic please. This RFC discussion is about an operator or family of functions to verify that a given $var is a c

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Thu, Jan 25, 2018 at 10:21 AM, Derick Rethans wrote: > > PHP owns the top-level namespace. It has always done that. It's even > documented: http://docs.php.net/manual/en/userlandnaming.rules.php > > That doesn't stop the bellyaching when the refactoring becomes necessary. If possible, it is be

[PHP-DEV][RFC][DISCUSSION] Collection Inspection

Ok, here's another idea I've been mulling over. This I know is possible because I've done it using user land code, specifically Drupal 8's Assertion\Inspector class. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x These methods p

[PHP-DEV] Website mangled because us1.php.net is down.

http://www.php.net is badly mangled, apparently because it's referencing files from us1.php.net and that server appears to be down at the moment. BTW, what should be the tag for this?

  1   2   3   >