[PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

Per PHPsadness... http://phpsadness.com/sad/30 Since 7 is allowed to have BC breaks this would be the time to fix this. I'll let someone with more seniority actually write this up - but please, please fix this - it's a very long standing annoyance.

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

It's not a feature though - it's a bug. It's just one of those bugs that the fixing of which may break something. On Thu, Mar 26, 2015 at 6:31 PM, Rowan Collins wrote: > On 26 March 2015 20:54:12 GMT, Michael Morris wrote: > >Per PHPsadness... > > > >http:

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

Rowan, I seriously, seriously doubt anyone would write PHP 7 compliant code that only takes advantage of ternary associativity, a feature that is only occasionally useful. If they can't take the hint from the parse errors arising out of the spaceship op and all the other stuff being added, they're

[PHP-DEV] List of possible E_RECOVERABLE_ERRORs

Hi. I hate to ask an outright question on the list rather but I've been searching the last 5 hours for an answer to this and haven't found anything and it's a rather tight corner case. I'm working on a small package for PHP 5.x that uses set_error_handler() to convert E_RECOVERABLE_ERRORs to the a

Re: [PHP-DEV] List of possible E_RECOVERABLE_ERRORs

ance on this - smoothing the transition from 5 to 7 helps all of us. On Tue, Jul 21, 2015 at 1:44 PM, Rowan Collins wrote: > Michael Morris wrote on 21/07/2015 18:11: > >> Hi. I hate to ask an outright question on the list rather but I've been >> searching the last 5 hours for an

Re: [PHP-DEV] Re: [PHP-DOC] missing docs for 5.4

Slightly off topic - but this is definitely a part of the PHP project I'm qualified to help (documentation writing) with in some capacity. Who would I get in contact with to get an assignment? Just the PHP docs list or someone specific? (I'm subbed to the internals list, I dunno if I'm subbed to

Re: [PHP-DEV] When is PHP6 Beta going to be available ;)

As far as I know, PHP 6 has been indefinitely postponed. Getting full unicode support turned out to be no mere bear, but an Arctotherium ( http://en.wikipedia.org/wiki/Arctotherium ). On Sat, Feb 4, 2012 at 3:26 PM, Lester Caine wrote: > I'm just looking into my annual dedicated server update s

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Having watched this discussion unfold, I for one intend to discontinue using Sushonin. I advise others to do the same. The character displayed by Stefan throughout this thread speaks for itself as to why. On Sat, Feb 4, 2012 at 9:44 AM, Stefan Esser wrote: > Pierre, > > I think we all know that

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

I don't think so. My experience with the attitude he has shown is, when mistakes get made by such a person, they are hidden away rather than honestly reported. To paraphrase a line from Harry Potter - brilliant people don't make many mistakes, but the ones they make tend to be large and very damag

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

On Mon, Feb 6, 2012 at 11:51 AM, Nikita Popov wrote: > On Mon, Feb 6, 2012 at 5:22 PM, Reindl Harald > wrote: > > if you anwer to a list mail answer to the list and not private damend! > Please, such kind of language is really not necessary. Hitting Reply > instead of Reply All happens to everyb

[PHP-DEV] $_PARAMETERS Super Global Object

Before writing up a full RFC I want to put out a feeler on something. Currently we have several input parameter objects, chief among them $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All of them are arrays and legacy code sometimes writes to them. Locking them as read only ob

Re: [PHP-DEV] $_PARAMETERS Super Global Object

tanding the full extent that you're suggesting. > > -- > Will Fitch > > On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: > > Before writing up a full RFC I want to put out a feeler on something. > Currently we have several input parameter objects, chief a

Re: [PHP-DEV] Scalar type hinting

What I've wanted for awhile, but don't know what the implementation problems would be, is to allow for two new variable types to solve this problem - Strict and tolerant variables. Both of these must be declared formally (otherwise PHP assumes scalar) and the datatype must be included. The syntax

Re: [PHP-DEV] Scalar type hinting

a copy. This will hurt the > performance in hardly predictable ways. > > johannes > > On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote: >> What I've wanted for awhile, but don't know what the implementation >> problems would be, is to allow for two new va

Re: [PHP-DEV] Scalar type hinting

I don't want it to be a strongly typed language. Whatever you call it (weakly typed, loosely typed), I want a change to where the *option* to declare a datatype exists. I do not want it to be required, both for backwards compatibility and also for barrier to entry reasons. In my mind given: (this

Re: [PHP-DEV] Scalar type hinting

Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw wrote: > OK everyone, it seems that some people have forgotten or missed the origina

Re: [PHP-DEV] Scalar type hinting

I don't think the strong/weak stuff is necessary at all. Either a programmer cares about datatype or they don't and the vast, vast majority won't. Declaring a variable's datatype should have the effect of locking that variable's datatype down and not allowing it to switch types with the sole exce

Re: [PHP-DEV] Scalar type hinting

t; I purpose to deal with this and when it works and is released to the > wild then see if more strictness even is needed. I think this simple > weak type hinted functionality will suffice. > > -- Forwarded message -- > From: Simon Schick > Date: 2012/2/28 > Subj

Re: [PHP-DEV] Scalar type hinting

Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = "1"; // no error. 1 == "1" so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Again, errors shoul

Re: [PHP-DEV] Scalar type hinting

rong type, since that would > now be done for you at the lower level.  There are other cases where this > sort of conflict would be undesirable but the coder might still want the > script to proceed anyway, hence the need for the weak type.  There are > valid, real-world use cases for both. &

Re: [PHP-DEV] HEADS UP: 5.4 branch is open again

PHP 6 comes out sometime around 2024 when, at PHP 5.27 Ramus decides to say, "screw it" - 6. Sorta like what happened with the Linux Kernel (which was 2.26 FOREVER) Tongue in cheek remark aside, we need to be cautious about avoiding using the major version tag (although the stupidity of the brows

[PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

I have made a wiki account with user name MichaelMorris - I don't think I have permissions to submit an RFC as of yet. I'll post this here for now. I've brought this up before, but can now simplify the original proposal since the decision to always have http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Namespace and Parse tags on Include and Require

Ok, with Hannes help I have the RFC up now. https://wiki.php.net/rfc/changes_to_include_and_require -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

On Tue, Mar 6, 2012 at 11:40 AM, Ferenc Kovacs wrote: > > I don't like this, I mean one can end up printing out his sourcecode if > - those files are publically available through the document root This can also occur if the server is mis-configured. That said, one way to deal with this. One wou

[PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

https://wiki.php.net/rfc/php_ini_bcmath_default This is the only other RFC I've been rummaging around in my head but hadn't brought up. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

On Tue, Mar 6, 2012 at 4:18 PM, Anthony Ferrara wrote: > I initially like the concept (arbitrary precision operations). > > But please don't add another ini setting.  Especially one where > *logic* can change depending on the setting.  I don't want a case > where pow(2, 65)-1 will return different

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

On Tue, Mar 6, 2012 at 4:31 PM, Anthony Ferrara wrote: > > Actually, I see that as even worse.  Why would 2 * 4 be possible to be > different from pow(2, 3)?  That doesn't really make sense (to me).  I > think if it was added, all of the math related extensions would need > to be (should be) upda

Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.

On Tue, Mar 6, 2012 at 4:47 PM, Tomas Kuliavas wrote: > 2012.03.06 23:03 Michael Morris rašė: >> https://wiki.php.net/rfc/php_ini_bcmath_default >> >> This is the only other RFC I've been rummaging around in my head but >> hadn't brought up. > > PHP h

Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require

2012/3/6 Ángel González : > Tagless files interpreted as php is the wrong way to go. > I think you should instead propose it as: > * A file included in that mode MUST begin with * ?> is forbidden in such mode unless followed by EOF. > > Ever work with older versions of subversion or vi? (Many ed

[PHP-DEV] [RFC] Specify namespace to include file into.

https://wiki.php.net/rfc/changes_to_include_and_require Since the reaction to the first of the two suggestions was largely negative I've withdrawn it for now to focus on the second of the two changes. In all honestly, these two suggestions should have had independent RFC's from the start. Of the

[PHP-DEV] Override keyword

Without cluttering the RFC list up further (I fear I've done too much of that with the last two bombed suggestions), I'd just like to come out and ask if the addition of an override keyword on classes had ever been considered? I'd see it as more than a self documenting thing for BC reasons than an

Re: [PHP-DEV] A possible defining characteristic of PHP 6 ( was [off] PHP: a fractal of bad design )

On Wed, Apr 11, 2012 at 11:19 AM, Luke Scott wrote: > I do agree with a lot of what was being said. But what can you do? It would not be easy. I lack the skills required. And those who have the skills lack the monumental time required. But PHP could do what Adobe did with Actionscript. But it

Re: [PHP-DEV] memory usage ouchy

What about a magic interface instead of a new base class, in a similar vein to the existing Array Access and Serializable interfaces. NonDynamic perhaps? On Mon, May 21, 2012 at 5:09 PM, Tom Boutell wrote: > Rasmus, isn't your concern about the impact of dynamic property > support on developers w

[PHP-DEV] Resume keyword

I can't get this out of my head after two weeks, but some part of me says this is a *really* bad idea. Of course another part of my brain things its a great idea and I'm getting tired of the argument. Resume is similar to return, but can only be used in catch blocks or in error handling functions

Re: [PHP-DEV] Resume keyword

On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs wrote: > 2012/6/20 Michael Morris > >> [/snip] >> >> An example for additional clarity. >> >> set_exception_handler(function ($e) { >>  echo $e->getMessage(); >>  // Don't know if this is co

[PHP-DEV] Braceless Syntax extended to functions and classes (bugs #47416 and 24100)

PHP has a braceless syntax stretching back to its roots as a template language. Frameworks which make use of php templating use these tags quite frequently since it's harder to overlook an endif statement in a sea of HTML tags than a brace. But what of endfunction? I did some look ups and found

Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning

Uhm... &= On Fri, Jun 29, 2012 at 6:09 PM, Paul Dragoonis wrote: > My input is that we should be focusing on features that PHP lacks, or > fixing bugs rather than adding more sugar syntax just for the sake of > adding it. > > On Fri, Jun 29, 2012 at 7:47 PM, Pierrick Charron wrote: > >> No probl

Re: Re: [PHP-DEV] 6.0 And Moving Forward

When Adobe moved from Actionscript 2 to Actionscript 3 they placed all existing functions into a legacy namespace. Similarly, I believe that may be PHP's best shot for smoothing out the API. Basically, the current function library is moved to the legacy namespace. The default setting is import t

Re: [PHP-DEV] 6.0 And Moving Forward

I want to clarify what I mean when I state that the existing API should move to a legacy namespace. First, the only reason to do this is if you want to change the behavior of functions to make them consistent. For example, Is it haystack, needle or needle, haystack? Second, how namespaces resolve

Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword

My thoughts are that no additional keyword is necessary - allow protected and private to be used in this scopes. A protected element of a namespace can be accessed within that namespace or any sub-namespaces, and a private element would only be visible by code in the same namespace. Hence namespa

[PHP-DEV] Hello - been pointed this way for suggestions - Including.

Been pointed this way by some folks that this is the place to set suggestions on changes to the functions or language. I have two at the moment, and that is to the including functions (include, require, include_once, require_once). They need to be considered separately as they address two different

Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

On removing globals / $GLOBALS, erm, -1 to that. Just too much legacy code needs this to work as is. On making $_POST, $_REQUEST, $_GET et al read only, again -1 for the same reason. However, I understand the sentiment and it brings up this idea... What about a new superglobal, $_INPUT, that is r

[PHP-DEV] PHP Dev RFC Selecting Namespaces and Tag styles at include time.

Been pointed this way by some folks that this is the place to set suggestions on changes to the functions or language. I have two at the moment, and that is to the including functions (include, require, include_once, require_once). They need to be considered separately as they address two different

[PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

Forgive me - it's been a *long* time since I've used a listserv, and I'm still getting the hang of getting the message tags exat. Reposting for those who may have missed this because I got the exact format of the tags wrong the first time around. On Thu, Dec 9, 2010 at 3:53 PM,

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

I've been giving some thought to the implication of my off the cuff addition of PHP_TAGS_NONE to the modes allowed and what should logically go with that. If tag style can be declared in a function, it should be possible set them in the configuration and at other places. Currently tag style is spre

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

Sun, Dec 19, 2010 at 11:22 AM, Matthew Weier O'Phinney < weierophin...@php.net> wrote: > On 2010-12-17, Michael Morris wrote: > > --0016e6daa93aab9e2004979f11fa > > Content-Type: text/plain; charset=ISO-8859-1 > > > > I've been giving some thought to th

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

eft at '0'. On Mon, Dec 20, 2010 at 4:52 PM, Stanley Sufficool wrote: > On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris > wrote: > > I'm not opposed to using a bitfield, but it's going to be tricky to do > > because there are two settings that want to be

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

That would make for an easier situation. If we don't worry about legacy for a moment that would give us this cleaner bitfield. Bit 0 -- Standard tags toggle 1 -- Short tags toggle 2 -- ASP tags toggle 3 -- Script tags toggle 4 -- Short echo toggle. For backwards compat ship with bits 0 and 3 set

Re: [PHP-DEV] RFC - Namespace initializers

One of the first things I tried when I seriously started exploring namespaces was the ideal of dynamic runtime loading. Consider class \A\Foo. I have a project that has \B\Foo extends \A\Foo. For that project though I want the autoloader to pull an unqualified request for "Foo" from \B\Foo even i

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

Bumping this after about a 3 week lull. How would I go about adding this to the wiki?? On Tue, Dec 21, 2010 at 11:43 AM, Michael Morris wrote: > That would make for an easier situation. If we don't worry about legacy > for a moment that would give us this cleaner bitfield.

[PHP-DEV] [RFC] Var_export tabbing

I've been trying to think of something that would be a good project to cut my teeth on for a first C project in forever and I'd rather work on something that might be useful. While cleaning tabbing on a var_export for a test class I think I have an idea. What I'm looking for is two things. One, i

Re: [PHP-DEV] [RFC] Var_export tabbing

ave a gazillion arbitrary arguments for every possible use > case. > > For just the purpose of just learning C however, go ahead. Sounds like a > good start. > > Hannes > > On 24 January 2011 19:26, Michael Morris wrote: > > > I've been trying to think of someth

[PHP-DEV] RFC Dynamic Tag Styles, and No Tags

About two months ago I placed an RFC to the list on this and we had a pretty good conversation on it. I've started the process of brushing my C skills up to the this task. Before I begin with this I'd like to review this one more time - I made some changes from the original proposal. Since the or

Re: [PHP-DEV] EOL removed after ?>

The RFC I just posted also addresses this problem by not requiring all files to have tags at all. On Thu, Mar 10, 2011 at 11:59 AM, Hannes Landeholm wrote: > http://brian.moonspot.net/php-history-newline-closing-tag > > ~Hannes > > On 10 March 2011 17:42, Martin Scotta wrote: > > > > hi all, > >

Re: [PHP-DEV] proposed access modifier "silent" ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

I might come off rather crumudgeonly here, but these last few threads I've seen going across to silence notices have a common theme - "I wanna be a lazier coder." Which is fine - set the PHP error level to not show them. But don't ask the engine to be rewritten to encourage bad coding practices w

Re: [PHP-DEV] RFC: built-in web server in CLI.

Since the goal of this is debugging might I suggest borrowing a statement from the Adobe Flash environment: trace. Trace sends output to the debug console. If given a variable it would format it as print_r currently does. When encountered by PHP in other modes it would be silently ignored. Tho

Re: [PHP-DEV] RFC: built-in web server in CLI.

#x27;s arguments are sent to console instead of browser. On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris wrote: > Since the goal of this is debugging might I suggest borrowing a statement > from the Adobe Flash environment: trace. > > Trace sends output to the debug console. If

Re: [PHP-DEV] RFC: built-in web server in CLI.

n Tue, Apr 19, 2011 at 10:29 PM, David Muir wrote: > I'm not sure if this is needed when there are already solutions for this. > eg, syslog, error_log, or other userland solutions like Zend_Log, > sfLogger, etc. > > Cheers, > David > > On 19/04/11 23:44, Michael Morris

Re: [PHP-DEV] 5.4 again

Question from the peanut gallery. Is the removal of magic_quotes and register_globals going to be done on this release, or is that still being put off for PHP 6?

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

Some time ago I floated this idea without any traction. I wanted to make an RFC but never got any help in setting up an account to submit it. Here it is again: Tag style can be set from the ini file, htaccess/httpdconfig or changed at runtime. If changed at runtime it only affects files that hav

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

Something I would add to this - I personally do use short tags in an open source project because mod_rewrite functionality, implemented either at the .htaccess level or at the httpd.config level. In either event, if you can use mod_rewrite, setting the php flag for short tags is trivial so I know i

Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*

This member of the peanut gallery would like to point out the following danger. Consider the following function collection for namespace A. namespace A; function strpos() {} function myfunc() {} Now if I understand the RFC correctly there's an unintuitive problem as follows - if myfunc is ca

Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*

I'm not so sure about that. For example, class PDO is PHP core. Suppose I create A\PDO. When PHP is asked for A\PDO and fails to find it then it will die. Correct me if I'm wrong but I think it does NOT go looking for \PDO. Another bugbear is classes will most likely be 1 class = 1 file. Funct

[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

[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

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

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 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.

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

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

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: [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

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

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

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

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 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

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

[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

[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

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

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] 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 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] 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

[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 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

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] [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 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 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 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 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 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

[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][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] 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] 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

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 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 >

  1   2   3   >