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?

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf wrote: > If you stay away from trying to change a 25-year old loosely typed > language into a strictly typed one, then the RFC becomes much simpler. > > -Rasmus > I have REPEATEDLY stated that is not the goal. I don't misrepresent what you say, p

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf wrote: > > > On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris > wrote: >> >> Also, drawing the architectural drawings for a skyscraper is also like >> only >> 10% of the work, but it's a damn important 10

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 10, 2018 at 12:53 AM, Rasmus Lerdorf wrote: > > The difference here is that the end syntax is something like 10% of the > problem. 90% of it is fitting it into the engine in an efficient manner > giving that it is affecting the very core of the engine. An RFC on this > issue that does

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Before I begin, and without picking on anyone specific, I want to say that it is generally unhelpful to say that because I, or others, do not know how the engine is set up that it is impossible to make any meaningful contributions to the list or on this issue specifically. My clients don't underst

Re: [PHP-DEV] Deprecation of assert() with string argument

On Sat, Jan 6, 2018 at 7:36 AM Christoph M. Becker wrote: > Hi everybody! > > As of PHP 7.2.0 calling assert() with a string argument has been > deprecated[1]. However, it seems that ASSERT_QUIET_EVAL / > assert.quiet_eval is supposed to only work as documented, if a string > argument is passed[

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Thu, Jan 4, 2018 at 7:21 PM Rasmus Lerdorf wrote: > > > On Jan 4, 2018, at 13:09, Andreas Hennings wrote: > > > > A system where all variables are type-locked could in fact be faster > > than a system with dynamically typed variables. > > Depends on the implementation, of course. I imagine it

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

Second Draft based on the feedback upstream. Target version: PHP 8. This is a proposal to strengthen the dynamic type checking of PHP during development. Note - this is not a proposal to change PHP to a statically typed language or to remove PHP's current loose typing rules. PHP is a weakly type

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 3, 2018 at 3:26 PM, Rowan Collins wrote: > Hi Michael, > > On 02/01/2018 10:35, Michael Morris wrote: > >> I would like to propose a clean way to add some strong typing to PHP in a >> manner that is almost fully backward compatible (there is a behavior >

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 3, 2018 at 12:21 PM, Andreas Hennings wrote: > Another idea I have when reading this proposal is "implicit" typing > based on the initialization. > > E.g. > > $x = 5; > $x = 'hello'; // -> Error: $x was initialized as integer, and cannot > hold a string. > > No, no no. I don't think

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 3, 2018 at 12:10 PM, Andreas Hennings wrote: > This proposal contains some interesting ideas, which I see as separate: > 1. A syntax to declare the type of local variables. > 2. A syntax to declare the type of object properties. > 3. Preventing local variables, object properties and p

Re: [PHP-DEV] Mailing list moderation

On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler wrote: > On Wed, Jan 3, 2018 at 10:49 AM Paul Jones wrote: > > > On Jan 2, 2018, at 12:29, Dustin Wheeler wrote: > > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison wrote: > > > > If someone dislikes Tony's commentary for any reason (or no reason!

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller wrote: > Hey Michael, > > I don't think the BC break is acceptable. You argue that scalar type > declarations are relatively new, but in fact they're already years old now. > They're used in most PHP 7+ packages. Even if changing types might be > disc

Re: [PHP-DEV] Re: Mailing list moderation

On Tue, Jan 2, 2018 at 6:47 AM, Derick Rethans wrote: > On Tue, 2 Jan 2018, Nikita Popov wrote: > > > This mail is going to both the systems group and internals mailing > > list. > > > > I would like to request a mailing list suspension for the users > > tonymars...@hotmail.com and li...@rhsoft.n

Re: [PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

On Tue, Jan 2, 2018 at 7:08 AM, Hidde Boomsma wrote: > Dear Michael, > > Are you aware of this RFC: https://wiki.php.net/rfc/typed-properties > > I was not aware of it. What I propose has a much wider scope, but the fact there was slowdown on the last implementation try is concerning.

[PHP-DEV][RFC][DISCUSSION] Strong Typing Syntax

Apologies for the double post - I missed a tag and I'm not sure the list server will send it along because of that mistake. I would like to propose a clean way to add some strong typing to PHP in a manner that is almost fully backward compatible (there is a behavior change with PHP 7 type declara

[PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

I would like to propose a clean way to add some strong typing to PHP in a manner that is almost fully backward compatible (there is a behavior change with PHP 7 type declarations). As I don't have access to the add RFC's to the wiki I'll place this here. Before I begin detailing this I want to emp

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

This was supposed to go to the list as well. On Mon, Jan 1, 2018 at 6:15 AM Michael Morris wrote: > On Mon, Jan 1, 2018 at 6:01 AM Lester Caine wrote: > >> On 31/12/17 22:45, Michael Morris wrote: >> > Please do not quote large swaths of Tony Marston's crap. He&

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine wrote: > > Not being able to vote, many of us have no option to complain about the > way things are going. Currently there seems to be several styles of PHP > form the nice and simple untyped version I moved to from very strictly > typed hard compiled

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

What would it hurt to allow instanceof to return types other than object? $x instanceof NULL $x instanceof string and so on. This would be more powerful and useful than throwing an error where one wasn't being thrown before. It also would let one operator detect all the types, rather than the pl

Re: [PHP-DEV] [RFC] Mixed Typehint

On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec wrote: > Hello internals, > > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint > > The purpose of this RFC is to introduce "mixed" typehint on language level > to be used > as a valid typehi

  1   2   3   >