Это просто синтаксический сахар.
Например разработчику проще воспринять.
new MyProxy(target);
чем
let myHandlerProxy={....};
.......;
new Proxy (target,myHandlerProxy);
Если вы консервативны, вас спасет и такой вариант при объявлении класса MyProxy
new Proxy(target,MyProxy.prototype);
Помимо этого конструктор подразумевает, что можно подготовить или обработать таргет под проксирование так как вам необходимо.
Далее развивайте фантазию.
Почитал доку Tracy. Там при анализе объектов и массивов, есть ограничение по глубине вложений. Я в свое время встретился с таким же ограничением в PhpConsole и отсутствием детализированных данных. Это меня и побудило написать собственную реализацию по анализу массивов и объектов. В моем случае можно анализировать толстые объекты и массивы с неограниченной вложенностью. Конечно может возникнуть ошибка memory size, но она возникнет при очень жирных объектах. Пока это единственное ограничение. По степени необходимости, по этой части будет рефакторинг.
С объектом $modx со всеми его вложениями справляется в легкую. Также петли, не повлияют на анализ. Они вычисляются и исключаются.
А рекурсивная детализация объекта, не однократно спасала. Можно посмотреть как детализирует состояние объекта. через вызов \deb::dump($obj); Возможно есть другие компоненты которые я не до оценил. Но на меня нашло вдохновение написать что то собственное.
Когда сам смотрю, тоже кровь идет. Но сначала реализуешь идею, перекладывая мысли в код, потом ее приводишь в порядок. Но пока собираюсь духом привести все в порядок.
Проект является не только для MODX. Я написал его для себя. Просто поделился. Будет неоднократный рефакторинг и code review как руки дойдут. Но пока что работает, не хочу трогать и прокачивать.
Причин несколько.
Реализация по большому счету не должна интегрироваться в фреймворки или CMS, а выполняться параллельно. Один раз установил на dev машине, потом где необходим анализ, в том проекте и подключаешь. Изначально пользовался с помощью плагина. Но почему отказался от такой реализации*? А до инициализации события MODXInit сколько строчек кода пропустим*? Может необходимо отладить код в самом MODX? К примеру, в один момент необходимо было провести анализ Index.php, чтобы внести свою корректировку для мультисайтовости. А если код падает до инициализации компонента, то вычислить проблему вообще не возможно. Если PHPDump будет запускать ранее до запуска основного сценария, то проблемы можно отслеживать.
Например разработчику проще воспринять.
чем
Если вы консервативны, вас спасет и такой вариант при объявлении класса MyProxy
Помимо этого конструктор подразумевает, что можно подготовить или обработать таргет под проксирование так как вам необходимо.
Далее развивайте фантазию.
С объектом $modx со всеми его вложениями справляется в легкую. Также петли, не повлияют на анализ. Они вычисляются и исключаются.
А рекурсивная детализация объекта, не однократно спасала. Можно посмотреть как детализирует состояние объекта. через вызов \deb::dump($obj); Возможно есть другие компоненты которые я не до оценил. Но на меня нашло вдохновение написать что то собственное.
Реализация по большому счету не должна интегрироваться в фреймворки или CMS, а выполняться параллельно. Один раз установил на dev машине, потом где необходим анализ, в том проекте и подключаешь. Изначально пользовался с помощью плагина. Но почему отказался от такой реализации*? А до инициализации события MODXInit сколько строчек кода пропустим*? Может необходимо отладить код в самом MODX? К примеру, в один момент необходимо было провести анализ Index.php, чтобы внести свою корректировку для мультисайтовости. А если код падает до инициализации компонента, то вычислить проблему вообще не возможно. Если PHPDump будет запускать ранее до запуска основного сценария, то проблемы можно отслеживать.