On Fri, Sep 2, 2016 at 9:28 AM Christoph M. Becker <cmbecke...@gmx.de>
wrote:
> On 02.09.2016 at 16:57, David Walker wrote:
>
> > Poking around, I'm must not be understanding how TICK opcodes would
> > negatively impact the lookahead. It may be my newness, but the way I'm
> > reading the compilation of ZEND_AST_DIM, would not be suspect to random
> > TICK opcodes from impacting the lookahead. I see that for a single
> > ZEND_AST_DIM, compilation will recuse emitting all the FETCH_DIM_R
> opcodes
> > for it in succession. Whereafter, a subsequent call to
> zend_compile_stmt()
> > will emit the TICK if it was declared. It could also be that I'm unsure
> > what a test example would be that could inject the TICK into the middle,
> of
> > the DIM compilation.
> >
> > The same applies to the BEGIN/END silence, as they will be wrapped around
> > the entire compilation of the DIM opcodes. [1] has an example using both
> > ticks and silencing, which seems to work as intended emitting a single
> > warning (for the un-silenced access)
> >
> > I'm not exactly sure what you mean by debugging-opcodes here though,
> > however, unless someone is hooking into the compilation and compiling
> DIM's
> > in a different way, I don't see the inherent problems with the lookahead.
> >
> > I was thinking about the use of an exception, however, I think that'd be
> a
> > pretty significant shift. It would also be very odd that this case would
> > be the exception throwing one, whereas accessing via reference wouldn't,
> or
> > any of the undefined indexes wouldn't. It would also impact most user
> code
> > out there by needing to wrap variable array access in a try{}catch, which
> > would be imposing a pretty large change to php 8.0. That's why I didn't
> > really think shifting to an exception would be appropriate here.
> >
> > Thanks
> > --
> > Dave
> >
> > [1] - https://gist.github.com/bp1222/18d80e8ec962eba1ba75c99124191a0a
>
> I don't understand why we're even trying to hack this, let alone
> considering to throw an exception. Why don't we handle array
> dereferencing just like property access, which also might throw multiple
> notices, see <https://3v4l.org/v49i7>. If this is considered too much
> of a BC break for 7.2, we still could postpone that change to 8.0.
>
> --
> Christoph M. Becker
>
Christoph,
I somehow remember this being raised at some point during this RFC,
although I can't seem to find where now.
I'd offer that it shouldn't be doing that. I would be of the opinion that
when an error condition appears, it shouldn't cascade the errors onwards.
As such, your example there, I'd desire a single notice raised.
FETCH_OBJ_R could benefit in the same way I'm attempting the lookahead to
FETCH_DIM_R. Although, I'd be open to raising errors if that's what's
preferable.
Thanks
--
Dave
