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

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

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

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

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.

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 les...@lsces.co.uk wrote: I'm just looking into my annual

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 ste...@nopiracy.de wrote: Pierre, I think

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

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

On Mon, Feb 6, 2012 at 11:51 AM, Nikita Popov nikita@googlemail.comwrote: On Mon, Feb 6, 2012 at 5:22 PM, Reindl Harald h.rei...@thelounge.net 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

[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

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

, 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 among them $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All of them are arrays and legacy code sometimes writes to them

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

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 variable types to solve this problem - Strict and tolerant variables.  Both of these must be declared formally

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:

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 johncrens...@priacta.com wrote: OK everyone, it seems that some people have

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

Re: [PHP-DEV] Scalar type hinting

...@googlemail.com Date: 2012/2/28 Subject: Re: [PHP-DEV] Scalar type hinting To: Arvids Godjuks arvids.godj...@gmail.com Копия: Michael Morris dmgx.mich...@gmail.com, internals@lists.php.net Hi, Arvids I do understand your arguments ... For me personally it's mostly to separate between string

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 should

Re: [PHP-DEV] Scalar type hinting

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. --Kris On Tue, Feb 28, 2012 at 3:30 PM, Michael Morris dmgx.mich

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

[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 ?= available addresses much of the

[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 tyr...@gmail.com 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

[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 ircmax...@gmail.com 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

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 ircmax...@gmail.com 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

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 to...@users.sourceforge.net 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 has something similar

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

2012/3/6 Ángel González keis...@gmail.com: 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 ?php. * ? is forbidden in such mode unless followed by EOF. Ever work with older versions of

[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

[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

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 l...@cywh.com 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

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 t...@punkave.com wrote: Rasmus, isn't your concern about the impact of dynamic property support

[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

Re: [PHP-DEV] Resume keyword

On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs krebs@googlemail.com wrote: 2012/6/20 Michael Morris dmgx.mich...@gmail.com [/snip] An example for additional clarity. set_exception_handler(function ($e) {  echo $e-getMessage();  // Don't know if this is correct - but should be able

[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 dragoo...@gmail.com 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

[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

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

[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

[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, Michael Morris

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

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

by most people who use 'short tags' On Sun, Dec 19, 2010 at 11:22 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-12-17, Michael Morris dmgx.mich...@gmail.com wrote: --0016e6daa93aab9e2004979f11fa Content-Type: text/plain; charset=ISO-8859-1 I've been giving some thought

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

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 if

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 dmgx.mich...@gmail.comwrote: 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,

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

however, go ahead. Sounds like a good start. Hannes On 24 January 2011 19:26, Michael Morris dmgx.mich...@gmail.com wrote: 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

[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

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 landeh...@gmail.comwrote: http://brian.moonspot.net/php-history-newline-closing-tag ~Hannes On 10 March 2011 17:42, Martin Scotta

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

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.

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

instead of browser. On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris dmgx.mich...@gmail.comwrote: 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

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

PM, David Muir davidkm...@gmail.com 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 wrote: Pardon me for following up my own

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

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

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,

[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 rowan.coll...@gmail.com wrote: On 26 March 2015 20:54:12 GMT, Michael Morris tendo...@gmail.com wrote: Per PHPsadness... http

Re: [PHP-DEV] List of possible E_RECOVERABLE_ERRORs

from 5 to 7 helps all of us. On Tue, Jul 21, 2015 at 1:44 PM, Rowan Collins rowan.coll...@gmail.com 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 answer to this and haven't found

[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

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

On Mon, Jul 11, 2016 at 1:55 PM, Michał Brzuchalski < michal.brzuchal...@gmail.com> wrote: > 11 lip 2016 18:31 "Rasmus Schultz" napisał(a): > > > > > what's the actual added value of this sort of operator? > > > > The only direct value to the language is brevity - mere

[PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

On Sun, Jul 10, 2016 at 6:34 AM, Rasmus Schultz wrote: > > What you're really trying to accomplish is something like the ".." > operator found in some other languages - this is known as the "cascade > operator" in Dart, for example: > > >

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

Not replying to anyone in particular or quoting anything so I'll start afresh. This is with the topic though, but I'm going to step outside of the box a bit. PHP was a template engine at inception. It still is to some degree - hence braceless syntax. The argument can be made that while the

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] 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] [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] Deprecate PEAR/PECL & Replace with composer/pickle

Please be cautious - composer isn't a complete replacement for PEAR because it doesn't behave the same way. For the most part this is a good thing, but please consider the following. On not one but two occasions I was tasked after being hired with upgrading PHP versions from 4.x to 5.3. In both

Re: [PHP-DEV] Missing reflection info about strict types?

On Mon, Sep 5, 2016 at 5:49 AM, Davey Shafik wrote: > > > On Sep 5, 2016, at 02:38, Nicolas Grekas > wrote: > > > > Hello, > > > > It looks like we miss a way to check by reflection if a function/method > has > > strict types enabled or not. > > >

[PHP-DEV] Single Point of Entry Apps.

Something I was reminded of during the discussion of replacing pear with composer that I thought was worthy of it's own thread. Most PHP apps I've seen that use composer are single point of entry apps - that is there's one front controller, usually index.php, and .htaccess rules are put in place

Re: [PHP-DEV] Missing reflection info about strict types?

On Wed, Sep 7, 2016 at 4:13 AM, Leigh wrote: > > > As an aside, would you guys like to see a strict types indicator in debug > backtraces? I wrote a small patch for it back during development of 7, and > then forgot about it. > >

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Wed, Sep 7, 2016 at 3:52 AM, Tony Marston wrote: > > > Typical. You create a useful tool, get your users hooked, then walk away > and leave them dangling. > > No one owes you anything. You aren't entitled to get free updates to a free tool. If the author wants to move

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Thu, Sep 8, 2016 at 4:27 AM, Daniel Morris wrote: > On Thu, 8 Sep 2016, at 08:43 AM, Tony Marston wrote: > > Perhaps users could be prevented from making such basic mistakes if they > > had > > a 21st century web interface instead of the archaic command line. > > Why

Re: [PHP-DEV] Single Point of Entry Apps.

On Mon, Sep 5, 2016 at 1:47 PM, Andrea Faulds wrote: > Hi Michael, > > Have you looked into PHP application servers, where the PHP code itself > acts as the web (or FastCGI) server, and so can keep the whole framework > etc. initialised in memory between requests? > I have - it's

Re: [PHP-DEV] [RFC] Namespace-scoped declares

On Friday, September 23, 2016, Nikita Popov wrote: > Hi internals! > > I'd like to propose the ability of specifying declare directives like > "strict_types" at the namespace level. > > The broader context of this proposal is to provide a simple and usable > mechanism that

[PHP-DEV] Feature Request: inline pseudo-instruction

On Tuesday, October 4, 2016, Pascal KISSIAN > wrote: > « tell me what you need, and I would tell you how to do without it » is a > nonsense answer for me… > > > > I just told you about one among several cases

[PHP-DEV] [PHP DEV] Bugs, BC, Strict Mode??

I've seen a couple bug fixes come up that create BC breaks for the code reliant on the broken behavior. JavaScript has a opt in strict mode for this. Perhaps PHP could do the same. An opt in mode with the declare directive that turns on bug fixes that are BC problems. One recent example, the

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

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

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

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

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

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

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

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

  1   2   >