On Wed, Aug 28, 2019 at 10:28 PM Matthew Brown
wrote:
> Javascript has treated undefined variables as a catchable exceptions since
> (I think?) forever. Perl is the only other language I know that allows them.
>
That isn't the point (I alluded to the fact that JS dealt with something
*similar*
Hey Benjamin,
On Thu, Aug 29, 2019, 05:09 Benjamin Eberlei wrote:
>
>
> On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas
> wrote:
>
>> Le sam. 4 mai 2019 à 18:37, Marco Pivetta a écrit :
>>
>> > Hi Steven,
>> >
>> > As it currently stands, the array cast is the only operation capable of
>> >
On Wed, Aug 28, 2019 at 10:26 PM Nikita Popov wrote:
> On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov
> wrote:
>
> Reading this discussion has been disappointing and somewhat disillusioning.
> I can understand and appreciate the concern for legacy code. But seeing the
> use of undefined
> On 28 Aug 2019, at 23:04, Chase Peeler wrote:
>
> On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote:
>
>> 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
On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas
wrote:
> Le sam. 4 mai 2019 à 18:37, Marco Pivetta a écrit :
>
> > Hi Steven,
> >
> > As it currently stands, the array cast is the only operation capable of
> > exposing object state without triggering any kind of access guards: it is
> > very much
On Thu, Aug 29, 2019, 12:33 AM Stanislav Malyshev
wrote:
> Hi!
>
> On 8/28/19 4:23 PM, Matthew Brown wrote:
> > $foo++ becoming 1 when $foo is undefined is not intuitive to me.
>
> I guess we have different intuition.
>
> > To take a very trivial example, that behaviour causes “for ($i = 0;
> >
Hi!
On 8/28/19 4:23 PM, Matthew Brown wrote:
> $foo++ becoming 1 when $foo is undefined is not intuitive to me.
I guess we have different intuition.
> To take a very trivial example, that behaviour causes “for ($i = 0;
> $i < 10; $I++) {}” to loop indefinitely.
This is rather shallow issue,
$foo++ becoming 1 when $foo is undefined is not intuitive to me.
To take a very trivial example, that behaviour causes “for ($i = 0; $i < 10;
$I++) {}” to loop indefinitely.
> On Aug 28, 2019, at 6:52 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> This is where I think PHP may have broken us a
Hi!
> This is where I think PHP may have broken us a little.
I think it's in no way "broken" to be able to easily match expectations,
like $foo++ always do what you meant without clunky boilerplate.
Also, if you think PHP is the only language I program in daily (and I
mean every day, except some
This is where I think PHP may have broken us a little.
I just asked a few non-PHP developers here what they expect "(function () {
$a++; })()" to do, and they agreed it would be some sort of error. Got the
same answer for "(function () { $a->bar = 5; })() ".
Indeed, anyone who's used another
Hi!
> If we want PHP to be as easy as possible then $nullref->bar(),
> $foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions
> either - they can just be notices.
I don't see how it follows. Calling unknown method does not have natural
default - if I tell you "would you please do
> If we want PHP to be as easy as possible then $nullref->bar(),
> $foo->someUndefined(),
> new UndefinedClass etc shouldn’t be exceptions either - they can just be
> notices.
That's very different. Note that this code doesn't even generate a notice:
$x = null;
var_dump($x+1);
I'm joining
If we want PHP to be as easy as possible then $nullref->bar(),
$foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions either -
they can just be notices.
> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Javascript has treated undefined variables as a
Hi!
> Because it's explicit, and incrementing null is mathematically
> unintuitive. After all, null does not exist anywhere in the set of
It is well-established in programming that default value for numeric
types is 0 (many Java IDEs, for example, will explicitly tell you if you
initialize a
I am already a minor contributor on github (with the same ID).
My immediate scope would be documentation fixes / updates, but I also wish to
keep fixing bugs for the time being.
No write access for the tree is okay to begin with, I guess I may keep the
GitHub flow for PRs currently.
On 28/08/2019 20:48, Stanislav Malyshev wrote:
Sure, that works. But I don't see any way this clunker is better than
$counts[$key]++
Because it's explicit, and incrementing null is mathematically
unintuitive. After all, null does not exist anywhere in the set of
natural numbers, so Roman
Hi!
> Javascript has treated undefined variables as a catchable exceptions since
> (I think?) forever.
Which seems to be why I open a random Javascript file in our codebase
and see this:
var wikibase = wikibase || {};
wikibase.queryService = wikibase.queryService || {};
Hi!
> Besides, we have tools available for years now to make this behaviour
> more defined:
>
> $counts[$key] = ($counts[$key] ?? 0) + 1;
Sure, that works. But I don't see any way this clunker is better than
$counts[$key]++
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP
Hi!
> For example, I just recently fixed a bug, that did this: `$array['key'] +=
> $cost` - the array key was not initialised. Well, turned out that in this
> case instead of null, it actually grabbed some garbage number out of memory
This would be a serious engine bug that you should submit to
Hi!
> Don't build your business on a foundation of eggshells and then complain
> when something comes along that makes those eggshells crumble.
I think PHP has historically been much less "bondage and discipline"
language, strictly enforcing a particular programming paradigm, than
others (e.g.
Hi,
On Wed, Aug 28, 2019 at 11:33 AM 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
Hi!
> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
If you're working in an environment where you aren't sure if $foo has
been mentioned already or not (ideally, you never have to, practically,
you sometimes are) it's much easier to just do $foo++ than write code to
Javascript has treated undefined variables as a catchable exceptions since
(I think?) forever. Perl is the only other language I know that allows them.
I've written code in a lot of different languages. Many of those languages
(most notably Standard ML) forced me to think about how exactly data
On Wed, Aug 28, 2019 at 11:33 AM 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
On 28 August 2019 18:45:18 BST, Matthew Brown wrote:
>Kicking a house is a poor analogy IMO - most people don’t upgrade a
>major
>language version without first verifying that their code still works in
>the
>new version.
Probably. Most analogies fall down pretty quickly. I just feel like some
On Wed, Aug 28, 2019 at 2:32 PM Zeev Suraski wrote:
> On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown
> wrote:
>
> > We log 1 in every 1000 notices, and yes - being notice-free is a goal –
> > though not one with any particular timeline at the moment, because we can
> > just ignore the problem. I
On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown
wrote:
> We log 1 in every 1000 notices, and yes - being notice-free is a goal –
> though not one with any particular timeline at the moment, because we can
> just ignore the problem. I look forward to not being able to ignore the
> problem.
When
On Wed, Aug 28, 2019 at 2:06 PM Matthew Brown
wrote:
> I'm no management expert, but I'd be surprised if a boss who won't set
> aside time to fix a few undefined variables nevertheless green-lights
> rewriting everything in C#.
>
> It wouldn't be rewrite everything. It would be doing future
I'm no management expert, but I'd be surprised if a boss who won't set
aside time to fix a few undefined variables nevertheless green-lights
rewriting everything in C#.
On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote:
> On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
>
> > On 28/08/2019
On Wed, Aug 28, 2019, 5:12 PM Mark Randall wrote:
> On 28/08/2019 16:37, Chase Peeler wrote:
> > I'm also not the one that built it on the eggshells - I'm just the one
> that
> > is now in charge of developing the system that someone else left sitting
> > eggshells.
>
> That's a challenge which
Kicking a house is a poor analogy IMO - most people don’t upgrade a major
language version without first verifying that their code still works in the
new version.
And the PHP ecosystem is strong – it's possible to find out today if your
code is likely to break (on undefined variables) with both
On 28 August 2019 17:53:55 BST, Matthew Brown wrote:
>It's not breaking all the things - it's breaking code that should have
>been broken already, but somehow wasn't.
It's still breaking it though.
If you realise that a house is built badly and could be destroyed by a
well-aimed kick, you
We log 1 in every 1000 notices, and yes - being notice-free is a goal –
though not one with any particular timeline at the moment, because we can
just ignore the problem. I look forward to not being able to ignore the
problem.
On Wed, 28 Aug 2019 at 12:55, Zeev Suraski wrote:
>
>
> On Wed, Aug
> "It's like our company car still works, but it no longer tighter meets
> emissions
> standards so they won't let us take it into the city any more"
That's a very interesting way to describe error level changes of a language.
I wonder what happens when the manager asks - "What's with those guys
On 28 August 2019 17:45:50 BST, Marco Pivetta wrote:
>The point is that "some organisations do X" is always used as an excuse
>for
>turning language design mistakes into BC boundaries.
No. Things that break compatibility are compatibility breaks. It doesn't matter
if they were mistakes or
On Wed, Aug 28, 2019 at 5:22 PM 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 in vimeo.com’s
> 700K LOC codebase (the undefined variables are confined to our views).
>
Can you elaborate
It's not breaking all the things - it's breaking code that should have been
broken already, but somehow wasn't.
On Wed, 28 Aug 2019 at 12:38, Rowan Collins wrote:
> On 28 August 2019 16:05:13 BST, Marco Pivetta wrote:
> >A week for 700KLOC is *impressively low*.
> >Many organisations spend
On Wed, Aug 28, 2019, 18:38 Rowan Collins wrote:
> On 28 August 2019 16:05:13 BST, Marco Pivetta wrote:
> >A week for 700KLOC is *impressively low*.
> >Many organisations spend more time on *deciding* whether to upgrade a
> >patch
> >version of a dependency, and the tooling that vimeo has
On 28 August 2019 16:05:13 BST, Marco Pivetta wrote:
>A week for 700KLOC is *impressively low*.
>Many organisations spend more time on *deciding* whether to upgrade a
>patch
>version of a dependency, and the tooling that vimeo has provided to
>detect
>these issues is technically impressive, and
On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
> On 28/08/2019 16:37, Chase Peeler wrote:
> > I'm also not the one that built it on the eggshells - I'm just the one
> that
> > is now in charge of developing the system that someone else left sitting
> > eggshells.
>
> That's a challenge
FWIW: all the runtime notices in our codebase come from internally-created code.
Requiring declare(strict_variables=1) to get this (better) behaviour punishes
future users of PHP for our past mistakes.
> On Aug 28, 2019, at 12:05 PM, Thomas Bley wrote:
>
> Normally every code base has old and
On 28/08/2019 16:37, Chase Peeler wrote:
I'm also not the one that built it on the eggshells - I'm just the one that
is now in charge of developing the system that someone else left sitting
eggshells.
That's a challenge which at some point or another will face all
technical leads.
You have
Hello,
as many later posters in the thread have said - a lot of notices,
especially uninitialised variables, are classic technical debt.
For example, I just recently fixed a bug, that did this: `$array['key'] +=
$cost` - the array key was not initialised. Well, turned out that in this
case
Normally every code base has old and new code, some is actively maintained,
some is probably third-party maintained, some is unmaintained. Business
normally not calculates costs for upgrading, securing, GDPRing old code, so
bigger changes always leave some people behind.
I would prefer to write
On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote:
> 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
On Wed, Aug 28, 2019 at 11:12 AM Mark Randall wrote:
> 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
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 28/08/2019 10:33, Nikita Popov wrote:
Hi internals,
https://wiki.php.net/rfc/engine_warnings
This is an absolutely outstanding move and I certainly hope it gets
passed unanimously.
PHP as a whole has traditionally been a language that is insanely
forgiving of errors, in many cases
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
75 matches
Mail list logo
