var_dump($db); // db connection resource
setNull($db);
var_dump($db); // null

var_dump($db); // db connection resource
dosomething($db);
var_dump($db); // null

А что можно понять из этого?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Скрин мутный, потому что длинный. Хотел всю глубину трагедии показать.

Вот это и есть прозрачность. Понятность с листа и предсказуемость поведения.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin, я в вашем примере если честно вообще не понял, как вы определили что там, что-то не так. Я как человек реально не разбирающийся в регулярках, не понимаю что у вас там написано, как мне этот массив поможет ума не приложу.


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Регулярка тут не при делах.

Просто ты не понял, как бороться с дебаггером.

Массив, это текущая таблица переменных. Это дебаггер у меня из трассировки вытягивает.
Переменные, как положено, сверху вниз. Первая в массиве - первая в методе. Значит это переменная $routes. По логике скрипта видно, что она не может быть пустой. Потому что мы открываем конкретную страницу, а значит в роутер должен попасть GET параметр. Это очевидно.

Если переменная пуста, значит метод IRB_URL::iniGET() ничего не вернул. Можно пойти посмотреть, что там. Но если чуток знаешь код, то из таблицы переменных видно, что ожидается ключ "page", а мы запрашиваем "dummy". Вот и весь баг.

А вот из вашей трассировки вообще ничего не понять. Ну контейнер, ну диспетчер, ну роутер. Где что пропало...

Какой контейнер смотреть, куда что девалось... Конечно, порывшись в коде, можно разобраться. Но ведь нужно рыться. А доков нету. А зависимости не ясны. А значит прозрачность - 0.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

chee

twin, у волтера слишком намудрена маршрутизация, оно и понятно, он походу ёё писал сам. Возьму пример мою с использованием сторонего решения.

https://bitbucket.org/cheevauva/examplecms/...xamplecms#cl-50

Вот этот метод, не сложнее вашего. Устанавливаем массив правил, приходит исходящая строка, ищем соответствие по правилу, получаем результат.


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Сама маршрутизация и у него не так сложна на самом деле. Вам своя просто привычнее. Но дело вовсе не в ней, а в том, что если есть баг в этом вашем классе, добраться до него будет не так просто. Жаль, что вашу систему нельзя поставить, я бы показал.

UPD. А главное то, что вы оба соблюдаете принцип ООП, а вот разобраться в чужом коде - уже проблема. Уже считаете, что у него запутано. И ошибку так ни кто и не нашел. Ну кроме хозяина конечно.

А в моем не разобраться просто стыдно. Так что все же полгалочки за прозрачность я заработал, за второй полгалочкой приду, когда свою систему запустите.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Почему вы постоянно пишите, что ооп это какие-то рамки, почему нельзя отказаться от ORM ? Если приложение станет хайлоадом и если вдруг всё начнет тормозить из-за ORM его можно выкинуть и использовать чистый sql. Кто запрещает? Или где вы прочли, что это не ооп. Кому нужно ооп ради ооп? Могу делать, что хочу, могу в части приложения применять ооп подход, а в другой процедурный подход. Смысл в том, чтобы это всё легко расширялось. Если рассуждать как вы, то в php нет ни одного 100% объектно-ориентированного приложения или фреймворка, вот например в Yii 2 есть как вы это называете "просто удобный контейнер" и следуя вашей логике Yii 2 не является ООП-фреймворком, там же не "всё объект". В общем, у вас какое-то извращенное понятие ооп.

Santehnick