On Wed, Sep 18, 2019 at 12:51 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, Sep 18, 2019 at 6:32 PM guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > Nikita, > > > > I'd suggest to wait until the current vote ends and then open a new > > RFC to vote this one, otherwise it'll be disrupting. > > > > Err, to be clear, I'm not suggesting to change the RFC under vote. We have > enough drama without that ;) > > I certainly don't care about this enough to run it through a separate RFC > vote either. I'd like a simple consensus decision on a minor point. If > Chase & co tell me that "This is no problem for us, go ahead" or "This is > going to break all our code, leave it alone" that's good enough for me. > > I don't know if I should be flattered or concerned that I was called out by name :-) I also want to reiterate, for the record, most of my arguments in regards to breaking BC isn't "This will be hard for me" as much as it its "This will be hard for a lot of other users" - I would never ask for anything to be done based on a use-case that only applies to me. That being said, I don't really know what the impact to the rest of userland would be. Since you can't actually redefine constants, I would argue that defining a previously defined constant *IS* probably an error situation. We actually have a "local_constants.php" that's included at the top of "constants.php" file. We can then define things in the local_constants.php, "overriding" the value in the constants.php file. All of the defines in the constants.php are preceded with @ though. Not sure if @ will suppress exceptions, but if not, that can always be put in try/catch (it'll just be REALLY ugly :-)). Also, we're trying to migrate away from the constants to using YAML configuration files, which handle per-environment overriding much better, but I digress. I think that's a specific exception though, where we know that we might be trying to define an already defined constant, and don't want it redefined. In most cases, if you are defining a constant, it's because you want it defined to that value, and are not aware it already was defined. I find that a totally different situation than using $i++ without having done $i=0 first. > Context is that the current notice prevents constant propagation > optimizations. A warning won't help us either, but it would be the first > step towards making it an exception in the future, which *would* enable > those optimizations. > > So, this is a case where there is an advantage to the change beyond "We want things to be more strict" - As many of us have said, we aren't against BC breaks. We just feel they should provide something that makes the language functionally better at a level that justifies the break. > Regards, > Nikita > > > > > > On Wed, Sep 18, 2019 at 12:29 PM Nikita Popov <nikita....@gmail.com> > > wrote: > > > > > > On Thu, Sep 12, 2019 at 2:17 PM Nikita Popov <nikita....@gmail.com> > > wrote: > > > > > > > Hi internals, > > > > > > > > I've opened the vote on //wiki.php.net/rfc/engine_warnings. > > > > > > > > There are 4 votes, all of them independent. The first 3 are for > > specific > > > > cases that were controversial during the discussion, the last one is > > for > > > > the remainder of the proposal. > > > > > > > > Voting closes 2019-09-26. > > > > > > > > Regards, > > > > Nikita > > > > > > > > > > I just realized that I missed one notice here, because it is generated > > from > > > a different location: "Constant %s already defined" (The define/const > > will > > > be ignored and the previous value used.) > > > > > > It would be great to have that as an exception for optimization > reasons, > > > but as it's only a notice right now ... what do people think about > > > promoting it to a warning? > > > > > > Nikita > > > > > > > > -- > > Guilherme Blanco > > SVP Technology at Statflo Inc. > > Mobile: +1 647 232 5599 > > > -- Chase Peeler chasepee...@gmail.com
