[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Система инициализации компонентов.
Страницы: 1, 2, 3
chee
Цитата (twin @ 20.10.2015 - 17:14)
Ну если ты Yii2 самописом объявил, о чем говорить тогда. Пойду куплю коран и тоже объявлю джихад всем, кто хоть на полстрочки от объектов отходит. Неверные... У нас же пророк теперь есть. Тебя не Мухамед зовут? smile.gif

я смотрю слюнями уже брызгаешь, я твой фреймворк называю низкосортным самописом. Про код Yii я говорю, что он не идеален, но не так плох как твой. Так что читай внимательно, и не теряй голову. wink.gif

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
twin
Цитата (chee @ 20.10.2015 - 13:20)
я смотрю слюнями уже брызгаешь, я твой фреймворк называю низкосортным самописом.

Я еще ничего не написал, мне уже вирдикт поставили. biggrin.gif Где там фреймворк, три рабочих файла. Один по образу Yii сделан, так на него все шишки свалились. Да фиг с ним. Мне это не важно.


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

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

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

user posted image
chee
twin, кстати посмотрел AbcProcessor, так вот, он как-то уж очень переусложнен. Я не очень понял почему Configurator настраивает Service Locator. Почему SL не настраивает себя сам, просто бы передал туда объект конфигурации. Зачем посредник? зачем так усложнять, если можно проще?





_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Oyeme
Цитата
Покажите мне на примере, что имеется ввиду. Какая обработка ошибок еще нужна, мне не ясно.
Цитата (Oyeme @ 20.10.2015 - 12:41)
Ошибки нужно обрабатывать, а не прятять.
Ошибки нужно не обрабатывать, а исправлять. Их не должно быть вообще. Если это логические казусы, то тут отдельный разговор. Как обрабатывать ошибку отсутствия компонента? Если его нет, никакая обработка уже не поможет. Или что в конце концов имеется ввиду?


Цитата
Ошибки нужно не обрабатывать, а исправлять.


Для чего тут тавтология?

В том то и дело что Вы не обрабатываете их,Вы просто останаливате все приложение и выбрасываете на все на стэек.

Используя multiple exceptions Вы с легкостью можите определить в какой месте и в какой классе произошла ошибка и как ее "обработать".

Тоже самое что "деление на 0". Вы можите остановить всю аппликацию но можитье и обработать этот кейс.

Например с разными конфигурациями и с разными настройками у Вас могут быть разные результаты.

Если файл не найден то может посикать в "другом месте" , либо приминить другие действия.

Это лишь примеры , в каких действиях вы Можите что применять.

В Вашем случаи Ваш framework вообще закрыт от тестирования.

Я планирую получить "ощибки" разных типов ,при тестирование,а получу в итоге строчку с дампа.

В лучшем случаи я хочу сделать тысячи тест кейсов,в Вашем же framework 0.

Вы теперь понимаете что Ваш framework нельзя вообще никак протестрировать?
twin
Oyeme
АААА! Нет, это невозможно уже. Блин, я сейчас на коде покажу. Раз на словах не получается.

Вот это:
    class MyException extends \Exception{} 

try {

throw new MyException('AAAAA!!!');
}
catch (MyException $e) {
echo $e->getMessage();
}
Будет работать.

Ничего не мешает сделать хоть стопицот своих обработчиков. Хоть вложенных, хоть переложенных. Дебаггер ловит только неотловленные исключения, ошибки интерпретатора и trigger_error. И только тогда, когда он включен. Что я не так сделал?

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

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

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

user posted image
Oyeme
Цитата (twin @ 20.10.2015 - 14:24)
Oyeme
АААА! Нет, это невозможно уже. Блин, я сейчас на коде покажу. Раз на словах не получается.

Вот это:
    class MyException extends \Exception{} 

try {

throw new MyException('AAAAA!!!');
}
catch (MyException $e) {
echo $e->getMessage();
}
Будет работать.

Ничего не мешает сделать хоть стопицот своих обработчиков. Хоть вложенных, хоть переложенных. Дебаггер ловит только неотловленные исключения, ошибки интерпретатора и trigger_error. И только тогда, когда он включен. Что я не так сделал?

Как Вы будете тестировать свой framework?

Вы уже не используете исключения.
twin
Не использую - это другой вопрос. Пока мне это было не нужно. Вопрос стоял в том, что у меня в принципе нет такой возможности. Так вот она есть. А с отловом исключений отдельная тема. Мне они вообще не нравятся. Очень на GOTO похоже.

И вообще, ловить исключения нужно в контексте. А фреймворк, это система. Она должна кидать их юзеру, коли не так что пошло. Пусть сам голову греет. На то и дебаггер, и логер будет и тд. и т.п.

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

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

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

user posted image
twin
Цитата (chee @ 20.10.2015 - 13:37)
twin, кстати посмотрел AbcProcessor, так вот, он как-то уж очень переусложнен. Я не очень понял почему Configurator настраивает Service Locator. Почему SL не настраивает себя сам, просто бы передал туда объект конфигурации. Зачем посредник? зачем так усложнять, если можно проще?

Потому что есть принцип SOLID И это кстати один из основополагающих принципов махрового ООП. Локатор должен предоставлять доступ к объектам, конфигуратор - конфигурировать, и никакой разрухи, как сказал Преображенсский. smile.gif

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

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

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

user posted image
Oyeme
Цитата (twin @ 20.10.2015 - 14:43)
Не использую - это другой вопрос. Пока мне это было не нужно. Вопрос стоял в том, что у меня в принципе нет такой возможности. Так вот она есть. А с отловом исключений отдельная тема. Мне они вообще не нравятся. Очень на GOTO похоже.

И вообще, ловить исключения нужно в контексте. А фреймворк, это система. Она должна кидать их юзеру, коли не так что пошло. Пусть сам голову греет. На то и дебаггер, и логер будет и тд. и т.п.

Цитата
Пока мне это было не нужно


Без тест сценариев открытых и закрытых framework ничего из себя не предстовляет.





twin
Цитата (Oyeme @ 20.10.2015 - 14:58)
Без тест сценариев открытых и закрытых framework ничего из себя не предстовляет.

Не улавливаю связи между тестированием и отловом ексепшенов. Можно примерчик на моем коде, как это можно связать?

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

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

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

user posted image
twin
Santehnick
Убедительно. Спасибо. Не думал, что это так важно, обрабатывать по разному ошибки фреймворка. Ошибки PHP не сильно обрабатываются. Фатал и дело с концом. Каво там еще реагировать, исправлять надо. Но раз так заведено, мне не сложно. Поменял. Благо их там не много. smile.gif

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

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

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

user posted image
twin
Всё переделал на новый лад. smile.gif

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

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

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

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.