Поддержку? Там все интуитивно понятно, беглое ознакомление в течении полу часа раскрывает весь функционал.
Никаких подводных камней не задумывалось, все интерфейсы унифицированны и их меньше десяти.
Но как вы сказали — код написан студентом.
Если идея и архитектура выстрадана годами, и могла подняться на более высокий уровень методом проб и ошибок, то качество кода осталось низким.
Да, благодарю. Мне удобно использовать ваш код при разработке, ибо моя система не подразумевает обработку таких ошибок. А вместе очень удобно. В релизе конечно будет работать только моя.
лучше так не делать.
там не должно быть исключений уровня логики. допускаются только фатальные эксепшены, которые делают не более чем запись лог/отправка данных и выключают скрипт.
Ну глупость же.
Зачем мне всегда явно васю от мира откреплять. Пусть это инкапсулируется, а я сделаю просто delete vasya.
Многое повидал, но что бы «деструкторы тоже предназначены исключительно для освобождения памяти дочерних объектов», первый раз.
К примеру дерево где для каждого узла считается количество узлов ниже.
Что мне теперь нельзя в деструкторе сделать parent->ChildDetached(this);?
Обязательно это делать явно? Такой подход мне непонятен.
> В PHP есть чудесная функция register_shutdown_function(). В ней доступ к файловой системе есть.
Ясно что есть возможность извернуться в коде так что бы не наступать на это. Но пахнуть не перестанет.
Я в упор не могу понять что в принципе мне может запрещать писать в файлы, нарушается какая то логика, прадигма, или что?
Я просто хочу сбросить дамп, нельзя, канделябр? Круто.
> Ваша проблема, во-первых, в том, что вы переносите подходы к программированию из одного языка в другой, во-вторых, используете ненадежные конструкции.
К сожалению изза вики «Испытал влияние: Perl, C, C++, Java». Вот и подумалось.
Я ни в коем случае не говорю «мир, подстраивайся под меня». Я надеюсь что те кто пройдет путь подобный мне будет предупрежден, а те кто проходили вспомнят былое вместе.
Никаких подводных камней не задумывалось, все интерфейсы унифицированны и их меньше десяти.
Если идея и архитектура выстрадана годами, и могла подняться на более высокий уровень методом проб и ошибок, то качество кода осталось низким.
Доделаю до удобоваримого состояния и поделюсь.
Прочитав Тони Шея решил перейти на опенсорс.
ATTACK dragon и подобное. Библиотека проектировалась так что бы накладывать как можно меньше ограничений. «Гибкость наше все»©
Мечты открыть компанию имеются.
Путем переопределения Open, Connect, Close, Send, Recieve, Resolve — на любой.
Так же смею настоять на AS-IS?
там не должно быть исключений уровня логики. допускаются только фатальные эксепшены, которые делают не более чем запись лог/отправка данных и выключают скрипт.
в моей версии актуально, как там в последних не знаю
Там именно эти баги, и они не исправлены(судя по ответам)
Зачем мне всегда явно васю от мира откреплять. Пусть это инкапсулируется, а я сделаю просто delete vasya.
Многое повидал, но что бы «деструкторы тоже предназначены исключительно для освобождения памяти дочерних объектов», первый раз.
К примеру дерево где для каждого узла считается количество узлов ниже.
Что мне теперь нельзя в деструкторе сделать parent->ChildDetached(this);?
Обязательно это делать явно? Такой подход мне непонятен.
> В PHP есть чудесная функция register_shutdown_function(). В ней доступ к файловой системе есть.
Ясно что есть возможность извернуться в коде так что бы не наступать на это. Но пахнуть не перестанет.
Я в упор не могу понять что в принципе мне может запрещать писать в файлы, нарушается какая то логика, прадигма, или что?
Я просто хочу сбросить дамп, нельзя, канделябр? Круто.
> Ваша проблема, во-первых, в том, что вы переносите подходы к программированию из одного языка в другой, во-вторых, используете ненадежные конструкции.
К сожалению изза вики «Испытал влияние: Perl, C, C++, Java». Вот и подумалось.
Я ни в коем случае не говорю «мир, подстраивайся под меня». Я надеюсь что те кто пройдет путь подобный мне будет предупрежден, а те кто проходили вспомнят былое вместе.