Есть ли веская причина не использовать debug_backtrace с единственной целью определения класса, имени и списка параметров вызывающего метода? Не для целей отладки. В названии функции есть слово «debug», из-за чего я чувствую себя немного грязным, чтобы использовать его таким образом, но он соответствовал законопроекту для того, что мне нужно было сделать (единственная функция, которую можно вызвать из многих мест и необходимо вызвать вызывающий метод из другой системы). Это работает, но разве это еще плохая идея? Если да, то почему?
Он чувствует себя немного грязным, но, поскольку он хорошо документирован, выписан и избит до смерти в другом месте, PHP не является системой, предназначенной для элегантности.
Одна из чрезвычайно запутанных причин не использовать debug_backtrace для логики приложения – возможно, какой-то будущий разработчик, работающий на PHP, может решить: «это всего лишь функция отладки, производительность не имеет значения».
Если вас интересует «лучший» способ сделать это, вы, вероятно, можете использовать магические константы PHP для передачи в вызывающем методе и имени класса, а затем использовать объект ReflectionMethod для извлечения любой другой информации, которая вам нужна.
Я лучше поставил кавычки, потому что, хотя это было бы более чистым и правильным, накладные расходы на создание объекта Reflection могут быть больше, чем использование функции debug_backtrace.
Есть ли веская причина не использовать debug_backtrace с единственной целью определения класса, имени и списка параметров вызывающего метода?
Да. Дело в том, что это, как правило, плохой дизайн, если вашему коду требуется такая плотная связь, что вызываемый должен иметь эту информацию о своем вызывающем абоненте. Поэтому, если вы чувствуете необходимость использовать эту информацию, вы, вероятно, должны переосмыслить свой дизайн.
Постарайтесь, чтобы вызывающая сторона не нуждалась в том, чтобы эта информация выполняла свою задачу. Исключения, конечно, вращаются вокруг отладки, протоколирования и, в общем, других видов самоанализа кода (но даже там, остерегайтесь этого).
debug_backtrace – одна из функций обработки ошибок PHP. Руководство побуждает пользователей определять свои собственные правила обработки ошибок, а также изменять способ регистрации ошибок. Это позволяет вам изменять и улучшать отчеты об ошибках в соответствии с вашими потребностями. Это также означает, что производительность, получаемая от использования этих функций, незначительна.
Я думаю, что вы делаете это нормально.
Вы сказали в комментарии
Задача вызываемого абонента – вызвать тот же метод, который вызвал его на другом компьютере. Это делается для того, чтобы избежать использования различных функций API для всех возможных источников, что значительно уменьшило количество кода в системе. Все еще плохо
Поэтому вы хотите сделать следующее:
Предполагая, конечно, что вы используете HTTP-запросы, чтобы отключить удаленный вызов.
Это немного странная настройка. Если вы создаете систему с нуля, я предлагаю попробовать ее обойти. Если вы замаскируете его в унаследованную систему, то, полагаю, я понимаю.
Я бы предположил, что вы всегда будете более ясны, когда сможете. Ваше использование интроспекции волшебного стека может сэкономить вам немного кода, но другому разработчику ваш код будет полностью озадачен. Если вы пытаетесь передать имя класса и функции функции, которая ранее делала отражение. Тогда нет никакой двусмысленности в том, что происходит.
Правильный ответ заключается в том, что все в порядке . Алан указывает на неэтичность PHP, поэтому я не буду повторять его. Причина (не бояться) использования debug_backtrace в коде во время выполнения заключается в том, что PHP – это в основном контекстно-свободный язык. Каждая функция не знает и не может знать «намерение» вызывающего абонента без использования имен магических функций (например, в классе – например, __toString ()) при кастинге. Давайте рассмотрим случай, когда у вас есть класс, в котором (в методе) вы хотите предоставить доступ к свойствам вызывающего (внешнего) класса. Это действительно беспорядочно и подвержено ошибкам, чтобы пройти ($ this) через функцию API. (Особенно, если вы хотите array_map или call_user_func_array.)
например
<? class a { public $v = 'xyz'; function __construct($x,$y) { $b = new b(); } } class b { function __construct() { $start = microtime(); $x = debug_backtrace(); $end = microtime(); echo ($end-$start) . "\n"; print_r($x); $obj = $x[1]['object']; print_r($obj); } } $a = new a(1,2); ?>
Debug_backtrace предоставит вам доступ к контексту класса a в __construct of b. Теперь вы можете передать некоторые переменные состояния из текущего класса, не пропуская $ this вокруг или не пытаясь угадать его из имен классов или перекрыть его, поместив его в глобальные.
Для тех, кто интересуется временем, microtime был 2.7E-5. Достаточно быстро. Просто не помещайте это через некоторое время (1).
Я думаю об использовании debug_backtrace для отладки операторов mysql. Ада гораздо проще определить ошибочные или медленные запросы, когда в начале каждого запроса в журналах базы данных есть такой заголовок:
/*Called from /var/www/micimacko.php at line 28*/ SELECT count(*) FROM rofibeka;
Вопрос остается. Что касается производительности / надежности.