[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

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

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 >

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

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

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

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

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

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

s 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't been common practi

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

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

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

[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

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"

[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

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:

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

Re: [PHP-DEV] About assert()

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

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

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

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

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

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

February 2018 20:18:07 GMT+00:00, Michael Morris <tendo...@gmail.com> > 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 r

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

On Tue, Jan 30, 2018 at 2:24 PM, Levi Morrison <le...@php.net> wrote: > On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield <la...@garfieldtech.com> > wrote: > > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote: > >> On Mon, Jan 29, 20

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

On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta <ocram...@gmail.com> wrote: > > On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <tendo...@gmail.com> wrote: > >> The problem is that behavior has been around so long that any attempt to >> change it would incur a

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 <la...@garfieldtech.com> 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 <la...@garfieldtech.com> > > > > wrote: > > > Re

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

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

On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 29 January 2018 19:14:43 GMT+00:00, Michael Morris <tendo...@gmail.com> > wrote: > > The is_callable() > >above prevents iteration over generators, potentially consuming them > &

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

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'

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

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

On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller <m...@kelunik.com> wrote: > Michael Morris <tendo...@gmail.com> schrieb am Fr., 26. Jan. 2018, 02:06: > >> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <m...@kelunik.com> wrote: >> >> > >> >

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

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

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

On Thu, Jan 25, 2018 at 2:16 PM, Rowan Collins <rowan.coll...@gmail.com> 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 i

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

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

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

[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

[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

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

On Wed, Jan 10, 2018 at 9:04 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > > > On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris <tendo...@gmail.com> > wrote: >> >> Also, drawing the architectural drawings for a skyscraper is also like >> only >&g

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

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

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 >

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

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

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

On Wed, Jan 3, 2018 at 3:26 PM, Rowan Collins <rowan.coll...@gmail.com> 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 c

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,

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,

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

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

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

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

[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

[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

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 <tendo...@gmail.com> wrote: > On Mon, Jan 1, 2018 at 6:01 AM Lester Caine <les...@lsces.co.uk> wrote: > >> On 31/12/17 22:45, Michael Morris wrote: >> > Please do not quo

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

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

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

Re: [PHP-DEV] Changes in namespace importing

I'm sure the internal coders will correct me if I'm wrong on this, but as I understand it PHP has no notion of packages, yet many calls to modify how namespace importing works seem to be under the illusion that packages exist. This is understandable, packages are namespaces are terms used somewhat

Re: [PHP-DEV] Proposal: Rename image functions

No. Hell no. The last thing PHP needs is an ill thought out string of function name changes to further pollute the global name space. Further, merely changing the names isn't going to do anything. What would help is a massive clean and redo for PHP 8 in the same vein as Actionscript 2 to 3 had a

Re: [PHP-DEV] RFC - Array Of for PHP 7

On Thu, Nov 2, 2017 at 3:21 PM, Larry Garfield wrote: > > While I normally strongly agree with supporting all traversables, not > just arrays, in this case I don't think it works. Hmm.. You're right. Traversables would be best served by having another method to indicate

Re: [PHP-DEV] RFC - Array Of for PHP 7

Drupal 8 accomplishes this through assert() and a helper class. function foo ( array $a ) { assert( Inspector::assertAllStrings( $a )); } This could be improved by having an collectionof operator similar to the instanceof operator. function ( array $a ) { assert( $a collectionof string ); }

Re: [PHP-DEV] Re: Wouldn't Exception::getContext() be useful?

> wrote: > >On 21.10.2017 at 09:20, Michael Morris wrote: > > > >> Right now the only way I know of to see the context of an exception > >throw > >> is to pass it in.. > >> > >> throw new CustomException(get_definted_vars());

[PHP-DEV] Wouldn't Exception::getContext() be useful?

Right now the only way I know of to see the context of an exception throw is to pass it in.. throw new CustomException(get_definted_vars()); It would be very useful to have exceptions just have this as a method. set_error_handle had this ability, but it's now deprecated. I'm guessing there's an

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine wrote: > UTF8 introduces a level of complexity and can be used used in many > places in PHP, but it does seem that there is no drive these days to > make the core a clean UTF8 environment. This should perhaps be addressed > again

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

On Thu, Sep 7, 2017 at 10:23 AM, Andrea Faulds wrote: > What I want to change is how it behaves in other circumstances, i.e. > templating. > > Thanks. > > I get that, but I can think of one example where this innocent change might BC break something. You cite this change being for

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

> > > Would anyone object to me changing how PHP handles this so that only the > final ?> tag consumes its following newline, and only at the end of the > file? > > Captain Obvious here. It has long been the policy of many large PHP projects to not close the last PHP tag for this reason. This

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

On Tue, Jul 18, 2017 at 3:11 PM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 18.07.2017 um 21:02 schrieb Michael Morris: > >> >> >> On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net > li...@rhsoft.net> <li...@rhsoft.net <mailto:li...@rhsoft.

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 18.07.2017 um 20:39 schrieb Michael Morris: > >> Personally, I no longer directly use these calls, preferring instead to >> use >> Symfony's HTTP foundation clas

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

Personally, I no longer directly use these calls, preferring instead to use Symfony's HTTP foundation classes. Those in turn are, I understand, in the process of being converted to implement the common interface outlined here: http://www.php-fig.org/psr/psr-7/ I would be much more interested in

[PHP-DEV] Allow else after loop structures for,foreach and while?

Reading the array coalesce operator concept thread I thought of this. I think I've seen in another language but I'm not sure. Anyway, here goes... Allow else blocks to follow iteration blocks. The else block is executed if no iteration occurs for any reason. foreach ($array as $key => $value)

Re: [PHP-DEV] RFC proposal

On Fri, Jun 2, 2017 at 1:36 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 2 June 2017 18:21:34 BST, Levi Morrison <le...@php.net> wrote: > >On Fri, Jun 2, 2017 at 11:12 AM, Michael Morris <tendo...@gmail.com> > >wrote: > >> What about foreac

Re: [PHP-DEV] RFC proposal

What about foreach by reference, which is honestly the only time I use referencing anymore... foreach ($array as $key => &$value) { $value = someOp($value); } Is this also bad? On Fri, Jun 2, 2017 at 10:56 AM, Johannes Schlüter wrote: > On Fr, 2017-06-02 at 15:21

Re: [PHP-DEV] Add is_vectorlike($array) function

For what it's worth, the Drupal assertion inspector calls these "Strict Arrays" since that's what they are - arrays in the true sense of the term found in all other languages. What PHP is calling an "array" is more accurately a "map" or "hash" There is value in this validation -

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

On Fri, Feb 3, 2017 at 3:37 PM, Niklas Keller wrote: > > > There are more drawbacks to that syntax like no parameters looking pretty > weird: || => > > I can't think of a valid example of an arrow function without any arguments at all. These functions are very simple iterators

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

On Fri, Feb 3, 2017 at 3:34 PM, wrote: > I like the suggested syntax. The only drawback I see is that it inhibits > the future addition of union types for closures: > > |int | float $x| => $x > > Adding parentheses of course resolves the issue but looks a bit awkward: >

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

On Fri, Feb 3, 2017 at 12:53 PM, Levi Morrison wrote: > > > To that end, I'd like to gauge interest in a pure syntax based > > alternative that is similar to Rust and Ruby. > > Instead of: > > > > fn(params) => expr > > > > What about: > > > > |params| => expr > Looks

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield wrote: > On 01/31/2017 05:14 AM, Bob Weinand wrote: > >> >>> In the case that regular closures got auto-capture, would a `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e. disable auto-capture),

Re: [PHP-DEV] Fwd: Type Collection

When I wrote the Assertion Inspector in Drupal 8 much of the library was concerned with insuring that all members of an array where of type X, so having a language construct to enforce this would be useful. I'm no language architect, but I'll take a crack at it.. We already have this function

Re: [PHP-DEV] Typed properties problems

On Tue, Jan 17, 2017 at 4:52 PM, Stanislav Malyshev wrote: > Hi! > > > That's pretty messed-up right there. At least in the object cases there's > > an E_WARNING "Creating default object from empty value" - with the array > > case, nothing, it just converts your boolean into

Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes

Otherwise - it's a simple majority (>50%, or even just the option that got > the most votes in case of a 3-way or 4-way vote). > There are better options for choices of 3 or more than the most votes system and I strongly recommend that they be used. Allow me to present an example. Suppose we

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

On Thu, Nov 17, 2016 at 5:33 PM, Adam Baratz wrote: > > > I agree with this. We could end up with a different system if we look at > this holistically. Also, I'm not sure what the urgency in making this > change is. I'd rather be thoughtful about a substantive change like

Re: [PHP-DEV] Re: [RFC] Abolish 50%+1 Votes

The study of voting systems is a hobby of mine and I've encoding vote gathering algorithms implementing them before, so this gives me a bit of insight into the discussion at hand that I would like to share. The goal of any voting system is to reach a consensus, and while majority rule (regardless

[PHP-DEV] Type locked variables

Perhaps it's time to revisit the idea of allowing variables to have their types locked down. The keywords needed are already reserved. So... string $a = "hello"; int $b = 5; Once declared this way the variable's type won't change unless it gets unset. In normal mode PHP will coerce any

Re: [PHP-DEV] function overloading

On Tue, Nov 15, 2016 at 11:14 AM Dominic Grostate < codekest...@googlemail.com> wrote: > I think this may have been discussed before, but I was largely dismissed > because no one though it would be possible to implement. > > However assuming it is possible, what is the general feeling towards >

[PHP-DEV] Low Hanging Fruit

What are some outstanding bugs that should be relatively easy to fix that no one has gotten around to? Low hanging fruit as it were for beginning devs.

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint

On Mon, Oct 24, 2016 at 3:21 AM, Michał Brzuchalski <mic...@brzuchalski.com> wrote: > > > 2016-10-24 8:45 GMT+02:00 Michael Morris <tendo...@gmail.com>: > >> On Sun, Oct 23, 2016 at 3:39 AM, Michał Brzuchalski < >> mic...@brzuchalski.com> >> wrote:

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint

On Sun, Oct 23, 2016 at 3:39 AM, Michał Brzuchalski wrote: > Hi all, > > I would like to initiate discussion for Object typehint RFC > https://wiki.php.net/rfc/object-typehint > > This feature is developed to provide missing functionality which is needed > and quite easy

  1   2   >