Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <55000A88.1030909@lsces.co.uk>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <54FF8CED.5030701@gmail.com> <CAOsHV+sdkSnrB_ZSHE1T81rnBt1K58-_fOzt6-kjHpghmjV5kA@mail.gmail.com>
 <54FFC96D.6090004@gmail.com> <1579682575.9673.1426064704052.JavaMail.open-xchange@app06.ox.hosteurope.de>
 <55000A88.1030909@lsces.co.uk>
Date: Wed, 11 Mar 2015 18:43:50 -0300
Message-ID: <CAOsHV+sZbE3EMvxTe4esXaUebcA+GKnYbDLEdo8ZXXwY6UJBdg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c23816e8714905110a2a8f
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: marcio.web2@gmail.com (Marcio Almada)

--001a11c23816e8714905110a2a8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-03-11 6:27 GMT-03:00 Lester Caine <lester@lsces.co.uk>:

> On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
> >>> BTW, the current PHP silent behavior should be considered even more
> >>> > > confusing otherwise we
> >>> > > wouldn't have these measurements:
> >>> > >
> >>> > >
> https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world
> >> >
> >> > I'm not sure how these prove current behavior is "confusing". Yes,
> there
> >> > are bugs in the code, and I'm sure this feature will expose some of
> >> > those (previously harmless) bugs. At cost of the BC break. And don't
> >> > think a handful of libraries represent the vast universe of PHP code=
,
> >> > most of which we can't even see because it's not published anywhere.
> > What do you mean here?
> >
> > Again, introducing a warning isn't a real BC-break and as you says ther=
e
> are
> > bugs it helps nobody ignoring them. If you think so you can do that wit=
h
> all of
> > your own bugs by ignoring warnings/notices.
>
> I must say I was a little confused when I first saw this given the
> number of errors I got when addressing the E_STRICT ones on existing
> code. One ended up creating multiple functions with different arguments
> to get a clean set of code, but I had perhaps not even realised that
> adding extra arguments was not flagged.


A lot of people don't know it too, and they are shooting themselves on the
foot without
realizing it because PHP is currently silent about it.


> In practice my IDE setup is
> flagging warnings where variables are not used, and it seems that
> perhaps I'm in a 'safe place' because of the whole package rather than a
> particular 'bug' in PHP.
>
>
Your IDE is a tool you are using to be safe from the current PHP misleading
behavior.
It's fine to use tooling, but that's a basic feature that shouldn't require
special tooling.


> Most of the examples being shown are examples of simple bad programming
> practice that needs fixing anyway, and I would expect a proper code
> review to have picked them up, so don't see that adding the check in PHP
> is essential. It would however be a useful addition but in the E_STRICT
> category ... not that I want to maintain that, but being able to ignore
> those errors until such time as it is appropriate to fix them.


I think this is a valid argument to keep the E_STRICT error level option
for the secondary voting.
That's a very useful information, thanks :)


> The
> poorly checked code is the problem rather than PHP here, and I'm with
> Stas that it's probably being a bit heavy handed at this point in the
> PHP7 process. Actually I would be rather annoyed if the problems
> demonstrated have not already been cleaned up already?


The examples are not "poorly checked" code, they were retrieved on widely
used packages
we all rely, directly or indirectly. Both code and tests used in the
measurements are
maintained by experienced people and yet the problems found a way to lurk
(it's not a fault on the maintainers side).

I'd say it's enough information to improve the language, not to require
that people
should manually check their code more or use tool A or B.


> A tool to
> identify problems and get them cleaned before the main test is switched
> on helps everybody?
>
--
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Thanks,
M=C3=A1rcio

--001a11c23816e8714905110a2a8f--