Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101782
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
Date: Tue, 06 Feb 2018 09:24:53 -0600
Message-ID: <5254389.jkSIk9W2zd@vulcan>
In-Reply-To: <CALKiJKqYGT6ZjtOORVvE7HpQJgs2n-Gx1h3L_D=r8JYTkzu=+w@mail.gmail.com>
References: <CAOv67gvh_TM8B+ZvJeMwQDN7wnC+n7JiW78Ydk+V3wRjsXigBA@mail.gmail.com> <CAFMT4Nqz6Tdr3cGvoU2_k_dTRNcTiuqL--mkA26LeGwCjb6=tw@mail.gmail.com> <CALKiJKqYGT6ZjtOORVvE7HpQJgs2n-Gx1h3L_D=r8JYTkzu=+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3231673.1fgt8CO0Gg"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
From: larry@garfieldtech.com (Larry Garfield)

--nextPart3231673.1fgt8CO0Gg
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Tuesday, February 6, 2018 4:08:03 AM CST Rowan Collins wrote:
> On 6 February 2018 at 01:51, Levi Morrison <levim@php.net> wrote:
> > It's fine to ignore them as long as they fix them later. That's
> > precisely why I think E_STRICT is a good category for these notices.
> > If, however, they ignore them forever that's their fault; we are
> > simply providing advanced notice of a behavior we'd like to eventually
> > change.
> > 
> > Let me put "eventually" into perspective. We will probably have a 7.3
> > before we have an 8.0. This means that 8.0, the absolute earliest
> > version we could remove this feature, is at least 2 years away before
> > it reaches *any* of our users. Unless we extend it like we did with
> > the last 5.X release (and I think we probably should extend it) this
> > means that users can run their existing code on an officially
> > supported PHP 7 release for the next 4 years at the minimum. I am
> > fairly confident that for one reason or another it will delay another
> > year or two, putting it at 5-6 years.
> 
> I think for a lot of people the "forever" in your first paragraph and the
> "5-6 years" in your second paragraph will feel like the same thing. If the
> message is "this might be removed some time in the next decade", people
> will simply shrug and ignore it until an actual removal is announced;
> thinking as a cynical user, there's no guarantee the recommendation won't
> be changed back in future - we've had features "undeprecated" before.
> 
> As others have pointed out, even if you run an analyser over your own code
> base to add \ in the appropriate places, you can't turn on E_STRICT notices
> without being flooded until all your dependencies have done the same - and
> there's no compelling reason for them to do so.
> 
> That's why I think having some concrete benefit much sooner is the only way
> to stop people resenting this change. Build function autoloading in a way
> that it only works if you opt out of the fallback, and *then* deprecate the
> fallback mode, and it feels like progress rather than disruptive tinkering.
> 
> Regards,

Potential benefits of this change aside, I have to agree with Rowan on tactics.  
A carrot works much better than a stick in this case.  Remember also that many 
larger systems stay around and in production WAAAAAAAAAAAAY past their 
expected lifetimes; there are still poor souls running PHP 4, and I personally 
know of Drupal 5 sites still in the wild.  So even if the HEAD version of 
everything is updated within a year for such a change the long tail of what's 
running out in the world will lag badly.

That said, I'm not sure that function autoloading will be that big of a carrot 
for the major projects at this point.  Wordpress is going to ignore anything 
we do here anyway for at least 15 years, and pretty much every other project 
in existence has gone all-OOP or nearly-all-OOP at this point (good or bad is 
beside the point).  Namespaced user defined functions are rare in my experience 
outside of very specific libraries (such as functional tooling libs).  So "yay, 
you can now autoload namespaced user-defined functions" will likely be met with 
a lot of "what are those?"

--Larry Garfield
--nextPart3231673.1fgt8CO0Gg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEcBAABCAAGBQJaecjFAAoJEODDCsAxcWF3YlEIALLNU6J13yw9cAIWk/rlCB57
zZxtEMBxve+JUdnu7uldeYDVXpnGOcYMsOff53VwI1XYRLE7Sa0OcatDMgA2oB/l
mqs8pA8YHlZGS1Z0V/rlqxi6jYf4HQzGYVb4ycw0Uuo9bsdGGrmVOszKg8ordxBK
TDZy8wPJFw6uh8I1HrCE7gETs+JE1MmQASRmRnCx1w+IIgTOafgHvPiZEaAQ+cSv
4YB4PuefVVlmuctGAbpBLEmJRMqbocMB8Sok4sBvpgTIvKCKIMQpdLyzDbfeBtHW
9kEUAgQ0rb1ZS3T6+wXx1Tc+mEnX9vKw4uxWTCFkzktu7Ff+tSRdAR0xd/6HKuQ=
=cQ43
-----END PGP SIGNATURE-----

--nextPart3231673.1fgt8CO0Gg--