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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
