hmm, this is indeed weird. @everzet can you explain your choice there ?

@stof @dantleech I never seen methods starting from _ treated as public APIs by anyone. In all cases I've seen _ at the beginning of method name means it is part of the private API. Hence Prophecy ignores these methods.

@everzet I cannot remember now the use case, I do not program APIs with underscores. But it is perfectly valid - should prophecy really assume that nobody will ever need to do this?

Ok, so the SoapClient has a __soapCall method, which is public, but due to this it can't be mocked. I think since 2016 is almost over people defining visibility with leading underscores just have to deal with the fact that tooling doesn't work with their conventions anymore, perhaps?

PECL RedisCluster::_masters() also is "public", in their documentation, but cannot be mocked. Don't mock what you don't own, I know. I'm building an adapter for it now.

If this isn't going to be updated, how about we make it report an error when you try to mock a method beginning with an underscore? Or when you try to call one? It took me ages to figure out that Prophecy was just ignoring those definitions, an error would at least tell me what's happening.

As @frankdejonge mentions the SoapClient has public methods starting with __, like __soapCall or __getLastResponse. This methods can't be mocked 👎

well... dangit. I was using phpspec to tests a soap library. Specifically handing specific logging behaviors based on values stored in a SoapClient. Now I'm up a creek because SoapClient doesn't have an interface for settings values. Short term is the solution to use mockery or does someone have a workaround?

Its clearly documented there are exceptions inside PHP. Also everyone can just use native visibility if they really want something to be private. I was a good argument 6 years ago and its even better now. I can't remember the last time I've seen this convention used and I think we can let it die.

I'm going to optimistically open a PR. I hope we can change this so random people in the future don't run into this weird WTF an waste time on it.

Аhead of the 10th anniversary of this issue, I'll humbly remind: it still actual. Moreover, since version 1.17, its no longer possible to use reflections as workarounds, since whitelisted method names are now constant, not property. But version 1.16 (last one, when whitelist overriding was possible) does not allows usage of PHP 8.3+, so this issue is starting to pressure.

Thanks for the reminder. Looks like the merge request was out of date so I rebased. didn't get more then a passing review but maybe a bump on this issue will get some attention again?