Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68925 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52510 invoked from network); 6 Sep 2013 20:11:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Sep 2013 20:11:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=adam@adamharvey.name; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=adam@adamharvey.name; sender-id=pass Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.181 as permitted sender) X-PHP-List-Original-Sender: adam@adamharvey.name X-Host-Fingerprint: 209.85.223.181 mail-ie0-f181.google.com Received: from [209.85.223.181] ([209.85.223.181:52731] helo=mail-ie0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/E8-05619-6D63A225 for ; Fri, 06 Sep 2013 16:11:03 -0400 Received: by mail-ie0-f181.google.com with SMTP id y16so2668016ieg.40 for ; Fri, 06 Sep 2013 13:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamharvey.name; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=+0QyMWfnT9OVs1gtsoe93XqBFUnF2KrClr3EngNv5E0=; b=rlf54v2iUwQy/TUmSQCfcsesDRyGO4Y6DLDlCe9zygMih0Eh57w7ljEY9cosXRweS/ OvbV3hKLKt4KGKRJod0dNxVJghWU34riiZKP3Ion6U/H5uf3FQeqsXu2GB65m2Mlwg4p 4S+7gNWI+zyaoFHIwT0JJd1BJTrphICxxd7DE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+0QyMWfnT9OVs1gtsoe93XqBFUnF2KrClr3EngNv5E0=; b=AYBc6sR5Wb/mLW1w+8EllVvgJYaNSVk9tzuIs+wlI45AcsT4oMT1eDl7chcEy81vJy Xm4bzPjnNEzBP/6YLVW+tFxpHm4e3uu2bUcp1i3ZpvVoD1v5TziF7sioPss6Ip6SFLyM 0dw5Xkih16qsKcg6ZBi6tOAyPWRLVH0l1JOjY4BKRS4RB0n39s8HSPmdWD8viZdDaEu0 9EA30vcABYMhp9q3gp5EP+/ERd1P8tNSrHg0SUafbXK7MC1HdffzPlnVR9bJ/xPm52Qu UdygAdHpB7LOzJ+GAqbAwN5UXEDhv5BxWploYxkdOtvly6dYyuPxcNdEk+sfybXx/4Tc c1vg== X-Gm-Message-State: ALoCoQld3Fk4gZLeATWEiq6sNEifbj25P0KiQ1bPyxKxtj14tJQ2YJo0PWnuw4WqTLnPoABXs1bl X-Received: by 10.50.49.65 with SMTP id s1mr3091827ign.43.1378498260408; Fri, 06 Sep 2013 13:11:00 -0700 (PDT) MIME-Version: 1.0 Sender: adam@adamharvey.name Received: by 10.42.206.208 with HTTP; Fri, 6 Sep 2013 13:10:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Sep 2013 13:10:40 -0700 X-Google-Sender-Auth: ybQky7Plw1mE_Oq9Jr_gHBqOY1U Message-ID: To: Dan Ackroyd Cc: Nikita Popov , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] Named parameters From: aharvey@php.net (Adam Harvey) On 6 September 2013 13:01, Dan Ackroyd wrote: >> I'd say the odds are that those sorts of users are going to be writing > >> code that is required to be notice/strict clean anyway =E2=80=94 that's >> certainly been true everywhere I've worked that's had a "modern" >> codebase. > > Yes, so say you have a team that: > > * currently has a code base that is notice/strict clean > * wants to move to PHP 5.x which has named parameters > * have code which changes the param name in extends/implements > > Unless they rewrite their code, they wouldn't be able to upgrade next > version of PHP without losing their strict/notice cleaness. So how would = you > suggest they upgrade to the version of PHP with named parameters? At the risk of being glib, by cleaning up their parameter names. A team that's testing a PHP upgrade is likely capable of that, and the strict notices would give them the needed feedback in the early stages of testing. That's hardly a rewrite. > Also I'm not sure that having which error level is used actually changes = the > behaviour of the language in a meaningful way. It only suppresses a > particular warning message, which can be suppressed anyway with > error_reporting(0). I don't really care which level actually gets used (it could be anywhere from E_STRICT to E_WARNING from where I sit), but I don't think the error reporting for a particular feature should ever be controllable separately from PHP's global error reporting. These sorts of warnings are there to promote better practice. Adam