Exceptions thrown from an accessor reveal underlying implementation details

[cpriest]

Todo: Identify what the current output is and what is desired.

I favor masking the internal implementation detail of a get access from being shown as a function call to __getXXXX() to something else, but this may look funky in a backtrace. Need output of what it would currently show and proposals on how to make it look.

[nikic]

Possible implementation in nikic@7fee8dd. The output for the exception traces is shown in https://github.com/nikic/php-src/blob/7fee8dd675e89ab0e00739d9dd63be2a129bf1eb/Zend/tests/accessors/exception.phpt.

Foo->__setbar('test')
// becomes
Foo->bar->set('test')

I'm not sure what the best syntax here is, imho the above doesn't show well enough that it is a property. Maybe Foo->$bar->set('test')?

The above commit also fixes #16 by adding the property and accessor elements. It does not yet fix debug_print_backtrace or whatever it's called.

[nikic]

One thing I noticed while writing this is that currently the implementation segfaults when an exception is thrown from a getter. I fixed this by returning an uninited zval ptr. Additionally one should probably include the code for checking indirect modifications as it is done for __get (see https://github.com/nikic/php-src/blob/7fee8dd675e89ab0e00739d9dd63be2a129bf1eb/Zend/zend_object_handlers.c#L479). (Or create a common function for calling both, to avoid copying that code)

[cpriest]

I think that looks great, I'd prefer the Foo->$bar->set('test') format, that makes it pretty clear. Although if Foo is the class, most elsewhere it would be Foo::$bar->set('test').

If we need that additional code referenced on L479 I agree we should centralize it into a common function. Really, before the shadowing the getter code was leveraging all of that same code, I think it could be re-worked a bit to all use the same code. I've created #24 for that task.

[nikic]

Fixed by cb1ac84. They are now displayed as Foo->$bar->set('test') in the backtrace

[cpriest]

Very nice, love it.

[smalyshev]

I think this is wrong and should not be done.

[nikic]

@smalyshev You are free to elaborate as to why you think so ;)

[smalyshev]

I elaborated on this like 9000 times already, but here it goes again: we should not write code that its whole purpose is to misrepresent what is happening in the engine. Not only it is an unnecessary complication which needs to be done everywhere where we touch functions names and would inevitably lead to inconsistencies, it also is greatly confusing, as $bar->set('test') means $bar is an object, and method 'set' is being called on it. But that is not what is happening in reality - in reality, the setter is called on entirely different object and $bar is a variable that can be a number or a string or anything and is not the object of the set() call at all.

[nikic]

we should not write code that its whole purpose is to misrepresent what is happening in the engine.

This does not misrepresent what is happening in the engine. It says that a function $bar->set was called and that's exactly what happened.

Not only it is an unnecessary complication which needs to be done everywhere where we touch functions names and would inevitably lead to inconsistencies, it also is greatly confusing, as $bar->set('test') means $bar is an object, and method 'set' is being called on it.

This change removed the need to add checks everywhere the function name is touched. It's now displayed everywhere the same and through the same mechanisms that are used for ordinary methods.

But that is not what is happening in reality - in reality, the setter is called on entirely different object and $bar is a variable that can be a number or a string or anything and is not the object of the set() call at all.

[cpriest]

I agree, it makes numerous other places where function names are "shown" much more clear and it also makes it more difficult for developers to try and call these functions directly because the spec will not gaurantee those function names at all. In addition, there was the __set_state() issue by declaring a guarded property of _state.

This also obliterates issue #30 which we decided wasn't worth solving anyways. To me, this change is 100% win.

[cpriest]

I might add that I could see it being named slightly differently though, I do see Stas's points somewhat. In the end I'm okay with what it is (better than before) but also think that something like set:$Bar might be more clear...