Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103898 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40710 invoked from network); 30 Jan 2019 19:04:09 -0000 Received: from unknown (HELO mail-it1-f175.google.com) (209.85.166.175) by pb1.pair.com with SMTP; 30 Jan 2019 19:04:09 -0000 Received: by mail-it1-f175.google.com with SMTP id h193so11131978ita.5 for ; Wed, 30 Jan 2019 07:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I+vWkT6dTf9leDYd9hEFd2dm0T2fSrjsxuy9eYSvVtY=; b=eTg4J6wkQBtl3gfegPV6c6IeuraUXkOKsbDoxQ40wPo+1MPxo7lot7mGKr2elAm29S xtQg7if6Iq30XpiF+bLvmt0H03eOILE0Dqmu9mqtMWj8Yg0H3RlVysfkVCaw+fyqbBoo ywjJDg8utDV40lEAWixQs9EoPH9tXPGIFjLlw3PyBovTer8MOg1y94VEY1YGzuc9oHnz +8kfp3lRIRRH6jqql+uaJtur+z1jeYj9feQAYyxBIzYFszrNYLps+faTG4Vl9O/inRhD AjXnTt6CB79D9/uxI+rPz5LFq1uA6BpnEs1a2FIVtA0E32teqBrMZAiV299nesS15tJS 1deQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I+vWkT6dTf9leDYd9hEFd2dm0T2fSrjsxuy9eYSvVtY=; b=KY8d6K3bV9oxmhTaYuVJDRqmrrs3o4jiA+JZb+9dlHjQQ3pPHlQqXpzyzKt5yX/aNy VlDPqH+A4mLpL4oUum8j++Uxc7YEGKvUXXeZE3u4bLf+vEUQUFG78PigFuIrFnL+cSVu DJ/P2ALuZA2qYg3PrVpdAIjayq/beNLmNfC551rF4IK6E982VOD6dWxsVbOWhbcDgLIn WTzz1SBybWuzQTxal6FJkHep7MKlEVXN9EkkuvdKWmdSe9i1WpBR4gkfRPDqWUfMeeEZ MVBrWJ/RZ099AJrJwJUo5+SXGOQcgDPApwpn5IWVa7+7/V8+r2FW5rnIWTS7PNtwYgZ0 kF3A== X-Gm-Message-State: AJcUukfAQkz7Fn8XdZzR5JiDQulgJ74B5SggO9NUWXrdPO3CJteDrHGA dZOMUwoOxUvE9f0nSdWcKBP2TMeCftSyPWvT+JU= X-Google-Smtp-Source: ALg8bN7txWN7+/n3taAcJ1ivAFaLc101e06XJUH/vp9deh7xa7o1W+ms4Nw7/BMkYRT0Jl0b1Y3Uqv8Qttc5fWA4RKI= X-Received: by 2002:a24:de87:: with SMTP id d129mr16217012itg.110.1548863028711; Wed, 30 Jan 2019 07:43:48 -0800 (PST) MIME-Version: 1.0 References: <3837033.kzX6na9RhK@vulcan> In-Reply-To: Date: Wed, 30 Jan 2019 16:43:31 +0100 Message-ID: To: Andreas Heigl Cc: Larry Garfield , PHP internals Content-Type: multipart/alternative; boundary="000000000000a1f7a70580aec63f" Subject: Re: [PHP-DEV] Old style constructors in PHP-8 From: nikita.ppv@gmail.com (Nikita Popov) --000000000000a1f7a70580aec63f Content-Type: text/plain; charset="UTF-8" On Wed, Jan 30, 2019 at 4:38 PM Andreas Heigl wrote: > > > Am Mittwoch, den 30.01.2019, 09:30 -0600 schrieb Larry Garfield: > > On Wednesday, January 30, 2019 5:41:45 AM CST Nikita Popov wrote: > > > On Wed, Jan 30, 2019 at 12:11 PM Dmitry Stogov > > > wrote: > > > > Hi, > > > > > > > > > > > > I've just noticed that Wordpress-4.1 on PHP master started > > > > silently > > > > produce different output. > > > > > > > > The problem that PHP master started to ignore old-style > > > > constructors. > > > > > > > > They were deprecated in PHP-7 and PHP produced the following > > > > warning > > > > > > > > > > > > Deprecated: Methods with the same name as their class will not be > > > > constructors in a future version of PHP; ... has a deprecated > > > > constructor > > > > > > > > > > > > PHP master doesn't produce any warnings and just constructs a > > > > class > > > > without constructor. > > > > > > > > This silent behavior change may become a problem for porting > > > > legacy code > > > > to PHP-8, > > > > > > > > May be, it makes sense to emit fatal error in case of old-style > > > > constructor. > > > > > > > > > > > > Thanks. Dmitry. > > > > > > First of all, it is probably important to note that the RFC for > > > this ( > > > https://wiki.php.net/rfc/remove_php4_constructors) explicitly > > > specifies > > > that in PHP 8 methods with the same name as the class are > > > interpreted as > > > ordinary methods and no warning or error is thrown. I've CC'd Levi > > > and > > > Andrea, who authored this RFC. > > > > > > I think as an end goal, what the RFC specifies is preferable for a > > > number > > > of reasons: > > > > > > * You should be able to call your methods whatever you like. PHP > > > only > > > reserves the __ prefix for itself. > > > * The behavior is consistent with classes inside namespaces, where > > > methods > > > with the same name as the class are treated as normal methods for a > > > long > > > time already. > > > * The fact that a method has the same name as the class may be > > > completely > > > incidental if it comes from a trait (see > > > https://bugs.php.net/bug.php?id=77470). The trait does not control > > > in which > > > classes it may be used and which names those classes may have. > > > > Every Drupal 7 or 8 site includes classes that have a method name the > > same as > > the class name, on the assumption that it's safe to do for a normal > > method in > > current PHP versions. Making that suddenly a Fatal would be, er, > > bad. :-) > > > > As others have noted, this is easily solved with static analysis > > tools. > > There's been discussion of WP moving to a PHP 7-based version of PHP > > sometime > > this year (no promises, but that's the scuttlebutt), which would let > > them > > convert to __construct() universally and safely well before PHP 8 > > becomes an > > issue. > > AFAIK WP requires PHP5 already as the minimum PHP-Version. And AFAIK > __construct worked with that as well. So there should be no need to > wait for PHP7 readiness in WordPress to tackle this issue. > > Replacing the function-name-as-class-name constructors with __construct > should be possible without a BC-break already. Even with PHP 5.0 as a > min-requirement. > > Or am I missing something? > That's correct. The standard pattern is to do something like this: class Foobar { public function __construct($args) { ... } public function Foobar($args) { $this->__construct($args); } } This ensures BC even for cases where people are explicitly calling Foobar::Foobar() for some reason (e.g. because they don't know that parent::__construct() can be used even if the parent constructor is not named __construct). WordPress does use this pattern for their constructors. The original problem that Dmitry ran into is that WordPress 4.1 was released one year before PHP 7, so they obviously didn't do this constructor migration at that point in time yet. Nikita --000000000000a1f7a70580aec63f--