I, for one, am quite happy that it's fairly complicated and convoluted
to get the caller of a method, since it could lead to some seriously
incomprehensible code in the hands of someone who don't know what they
are doing. Requiring the user to use the backtrace is a clear warning
sign, and I think that's a good thing.
What is the basis for all this. When someone says a feature is "ugly" and it leading to "seriously incomprehensible code", I'd really like this is explained and supported by evidence somehow, than just thrown around without facts.
Most OOP languages expose the caller in some fashion. You'll be hard at work to see in which of them it led to masses of convoluted code.
Practical uses for the caller reference include:
- implementing private/protected members in __get, __set, __call. Currently they're all public, since PHP knows the caller, but userspace doesn't. Visibility is caller-based.
- implementing friend classes. When two classes in a namespace or a logical unit, want to communicate on "private matter", the only option is public methods/members. This can lead to a third party calling the code intended for internal use and breaking something somewhere. The only solutions today for properly capsulating such code are ugly & slow hacks (including debug_backtrace).
Regards,
Stan Vassilev