Hi
Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler :
> You going to come and fix the issues? It's an internal application and
> most of those messages are coming from legacy areas of the code which are
> mainly "it works, so leave it alone" things. Instead of going back and
> spending time
It's essentially tech debt, and the language has allowed its users to
accrue a ton of it.
The longer that's allowed (deprecations/warnings prolong the issue in my
opinion) the harder it will be to fix the issues.
On Wed, 28 Aug 2019 at 10:56, Rowan Collins wrote:
> On 28 August 2019 15:22:22
On 28/08/2019 15:54, Chase Peeler wrote:
Bottom line is that we live with the not-so-good stuff so that we can focus
on adding new great stuff. The not-so-good stuff isn't holding us back, and
trying to fix things like undeclared variables would have absolutely ZERO
positive effect on our
On Wed, Aug 28, 2019 at 4:56 PM Rowan Collins
wrote:
> On 28 August 2019 15:22:22 BST, Matthew Brown
> wrote:
> >Looking at our notice logs, I estimate (fairly roughly) that it would
> >require about a week's worth of my time to fix these issues
>
> I honestly thought you were posting that as
On 28 August 2019 15:22:22 BST, Matthew Brown wrote:
>Looking at our notice logs, I estimate (fairly roughly) that it would
>require about a week's worth of my time to fix these issues
I honestly thought you were posting that as an argument against. A week of
resource (plus the accompanying QA
On Wed, Aug 28, 2019 at 10:39 AM Marco Pivetta wrote:
> On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler
> wrote:
>
>> On Wed, Aug 28, 2019 at 10:20 AM Gert wrote:
>> Notices include a lot more than just undeclared variables. Turning them on
>> in our environment would pretty much make the logs
On 28 August 2019 15:39:26 BST, Marco Pivetta wrote:
>I worked with clients with much more log overhead happening: the
>solution
>is working to fix these issues, and not ignoring more of them.
Being right is not the same as being easy, or being the top priority for an
organisation with limited
On 28 August 2019 15:24:33 BST, Mark Randall wrote:
>By the very nature of using @ to suppress error messages, the examples
>given are all fully aware that the behaviour they are using is not good
>practice.
I think that is a fault in the examples. I have never seen @ used to squash
these
On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler wrote:
> On Wed, Aug 28, 2019 at 10:20 AM Gert wrote:
> Notices include a lot more than just undeclared variables. Turning them on
> in our environment would pretty much make the logs unusable for any on the
> spot checking for issues. They would
On Wed, Aug 28, 2019 at 10:20 AM Gert wrote:
> Maybe i'm misunderstanding something here, but what does turning
> notices into deprecations achieve? Because if you have deprecation
> notices being logged then it shouldn't be extra work to log
> notices/warnings as well right?
>
> Notices include
On 28/08/2019 14:48, Chase Peeler wrote:
My position is that this should be done as an opt-in feature like Zeev as
proposed. If it is not done as an opt-in feature, then I don't think it
should be done at all.
IMO one shouldn't have to opt-in to use common-sense error checking of
engine
Looking at our notice logs, I estimate (fairly roughly) that it would
require about a week's worth of my time to fix these issues in vimeo.com’s
700K LOC codebase (the undefined variables are confined to our views).
IMO it's akin to taking the training wheels off the language – I think the
PHP
Maybe i'm misunderstanding something here, but what does turning
notices into deprecations achieve? Because if you have deprecation
notices being logged then it shouldn't be extra work to log
notices/warnings as well right?
On Wed, 28 Aug 2019 at 16:16, Chase Peeler wrote:
>
> Well, one reason I
Well, one reason I was so vocal about short tags wasn't a love for short
tags themselves. It wasn't even to prevent the detrimental effects of
removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more
about the precedent that it set - pushing huge BC breaks on the users (most
of
On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald
wrote:
>
>
> Am 28.08.19 um 15:48 schrieb Chase Peeler:
> > If it is still done, then I think a deprecation path is a must. As
> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages -
> > warnings will work too. The key is that
On Wed, Aug 28, 2019 at 9:30 AM Chase Peeler wrote:
>
>
> On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote:
>
>> On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov
>> wrote:
>>
>> > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>> >
>> >>
>> >>
>> >> On Wed, Aug 28, 2019 at 12:33 PM Nikita
On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote:
> On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote:
>
> > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
> >
> >>
> >>
> >> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
> >> wrote:
> >>
> >>> Hi internals,
> >>>
> >>> I think it's
However, I feel pretty strongly that converting any of these to
> deprecations is not a good idea. While there's certainly different views on
> this, I've seen it often enough deprecation warning are considered an even
> lower error level than notices (imagine my surprise when PEAR stopped
>
On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote:
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>
>>
>>
>> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
>> wrote:
>>
>>> Hi internals,
>>>
>>> I think it's time to take a look at our existing warnings & notices in
>>> the
>>> engine,
On Wed, 28 Aug 2019 at 12:57, Nikita Popov wrote:
> However, I feel pretty strongly that converting any of these to
> deprecations is not a good idea. While there's certainly different views on
> this, I've seen it often enough deprecation warning are considered an even
> lower error level than
Am 28.08.2019 um 13:10 schrieb Nikita Popov :
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>> Specifically on undefined variables, the way we deal with them has little
>> to do with register_globals. It's behavior you can find in other dynamic
>> languages (e.g. Perl), and allows for
On Wed, Aug 28, 2019 at 1:46 PM Lynn wrote:
>
>
>
> This argument makes sense for arrays and objects (and I don't promote
>> undefined index/property to exceptions for that reason), but I don't think
>> it holds any water for simple variables. Writing @$counts[$key]++ is a
>> lazy
>> way to
This argument makes sense for arrays and objects (and I don't promote
> undefined index/property to exceptions for that reason), but I don't think
> it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
> way to count values and avoid ugly boilerplate for if
>
On Wed, 28 Aug 2019 at 10:33, Nikita Popov wrote:
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really
On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>
>
> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
> wrote:
>
>> Hi internals,
>>
>> I think it's time to take a look at our existing warnings & notices in the
>> engine, and think about whether their current classification is still
>>
On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov wrote:
> Hi internals,
>
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
Hi Nikita,
This RFC makes me very happy! I have a few points that I didn't find
clarification on in the RFC. For "Undefined variable: %s" the new proposal
is an Error Exception. For a starter: will it include dynamically declared
variables such as $$foo?
For my second point: in regards of
Hi internals,
I think it's time to take a look at our existing warnings & notices in the
engine, and think about whether their current classification is still
appropriate. Error conditions like "undefined variable" only generating a
notice is really quite mind-boggling.
I've prepared an RFC with
101 - 128 of 128 matches
Mail list logo
