Мне тоже (как и вашим друзьям-разработчикам) кажется, что это не самый удачный пример использования исключений.
Обычно, рекомендуют использовать исключения только в нештатных ситуациях, ни в коем случае не применяя их для управления логикой исполнения. И этому есть разумные объяснения. Исключения очень хороши во первых тем, что позволяют снять с кода бросающего исключение ответственность по его обработке, давая возможность среагировать на ошибку коду, который знает как это сделать. Исключения так же хороши тем, что в отличие от подхода с возвратом кода ошибок их невозможно игнорировать (это как раз к тому, почему они хороши для обработки нештатных ситуаций). Плюс вы получаете преимущества связанные с уменьшением дублирования и улучшения читаемости кода обработки ошибок.
Если же использовать исключения для организации логики, то в этом они подобны goto, если даже не хуже. Из одного места кода вы вдруг переходите в другое. Повсеместное использование исключений разрушает код. Конечно, грань очень тонкая. Неверные данные, введённые пользователем это штатная или не штатная ситуация? Это зависит от точки зрения разработчика и уровня кода работающего с данными (скажем, на уровне представления неверно введённые данные это нормально, если же вы пытаетесь сохранить объект с этими неверными данными в базу то наверное уже нет.)
В вашем случае без исключений вполне можно было бы обойтись. Было бы вполне достаточно вернуть из функции валидации объект с данными об ошибках. Я не вижу, как в этом конкретном примере полезны исключения.
Ну Кнут во первых не такой уж и теоретик. За свою жизнь, я думаю, он немало программ написал, например, известный TEX.
Вы понимаете смысл того что говорит Кнут, и другие известные программисты?
Они не утверждают, что программы должны быть медленными, они не говорят, что оптимизация не нужна или бесполезна.
Все эти цитаты о том, как её правильно проводить.
Нет смысла тратить усилия, и разрушать код (а оптимизация на уровне кода неминуемо делает его менее понятным) по всему проекту, если это даёт лишь жалкие десятые процентов прироста. Надо искать корень проблем с производительностью.
Конечно, можно постоянно заниматься оптимизацией в качестве интеллектуального упражнения, как предлагаете вы. Но в профессиональной разработке программ это не серьезно (пожалейте ваших коллег по команде, и тех кто будет разбираться в коде после вас).
А ещё Кнут выяснил что 50% производительности определяется 4% кода. Hot spots реально существуют и в большинстве проектов найти их профайлером не так сложно.
Ну вообще говоря, create_function это ужасный хак. Она создаёт функцию со случайным именем в глобальной области видимости, что не есть хорошо. К тому же, эта функция не может замыкаться на контекст (как в предлагаемом патче), в результате дополнительные параметры в неё очень проблематично передать, только как глобальные данные. Насчёт нежелания заводить новую функцию - так и не надо. Просто в примерах этого нет, но функцию можно будет написать прямо вместо параметра (так же как при create_function).
Наверное, стоит добавить: от множественного наследования интерфейса и реализации одновременно. А вот по отдельности - другое дело. Множественное наследование реализации в виде mixins (как в ruby при импортировании модуля в класс) это очень неплохая штука, позволяет избежать дублирования кода в сложных ситуациях.
Странно, что представлен такой небольшой процент использующих ExtJs. Конечно она предназначена скорее для веб приложений, чем для простых сайтов, но всё равно. Может быть, дело в жёсткой для комерческого применения GPL.
Надо обязательно продумать как подать основы ООП. То что написано в большинстве книг для университетского образования не выдерживает никакой критики. Это обычно набившая оскомину триада абстракция, полиморфизм, инкапсуляция. Чтобы понять что такое ООП этого недостаточно.
Надо обязательно рассказать и о других принципах: разделении интерфейсов, открытости-закрытости и т.д. (Ну вы знает, всё как в книжке у дяди Боба (Мартина)).
Ещё неплохо было бы написать о Domain Driven development.
Конечно, обязательно изложение паттернов проектирования. Возможно, хорошим вариантом будет рассказать о них параллельно с изложением принципов ООП, показав тем самым, как эти принципы отражаются в них и работают на практике.
В рефакторинге надо не забыть рассказать о важности юнит тестов (и может быть о TDD тогда уж), перечислить основные code smells.
В общем, надо наставить студентов на истинный путь. Убедить, что класс программиста определяется читаемостью его кода, что надо писать насколько это возможно понятный самодокументированный код и стремится к его совершенству :)
В итоге, учитывая ограниченный объём пособия, получится вот такой вот евангелизм на тему аджайл технологий. Главное чтобы он дал толчок к профессиональному развитию тем, кто действительно хочет стать хорошим разработчиком.
Python и php совсем разные языки. Php используется почти исключительно в вебе (ну и немножко в скриптовой автоматизации). Python - это язык общего назначения, на нём написано огромное количество программ под Linux, применяется в промышленной автоматизации.
Ввести табуляцию в синтаксис - это на самом деле очень здравая идея, ведь и так все блоки кода обычно форматируются табуляцией, так зачем плодить лишние синтаксические элементы.
Ну в таком несколько обзорном курсе, как я понимаю, конкретная платформа не особо и важна. Подойдёт и asp.net и rails и любой фреймворк под php. Гораздо важнее тут объяснить основные принципы качественного веб-приложения, рассказать об основных архитектурах, распространённых типовых решениях, да и вообще о правильной разработке в целом. Так сказать наставить на истинный путь.
А как кстати сделать цикл, повторяющийся очень большое число раз?
Ведь, как я понял range возвращает массив, при большом количестве очень длинных циклов это будет не лучшим образом сказываться на использовании памяти.
Как то Dell опаздывает. Hp, Acer, Asus, MSI свои нетбуки уже представили, а деловская машина вряд ли будет чем-то выделятся среди них. Цена тоже видимо к релизу подрастёт, как всегда это бывает.
Это значит он качественный, т.е. понятный. Хорошая объекто-ориентированная архитектура, логичное разделение классов по модулям, строгое следование кодстайлу.
А общем, код легко читается.
Но ведь проверке с обращением к домену тоже нельзя доверять. это решение только для виртуального хостинга, если есть доступ к ос сервера ничего не стоит подменить домен.
Обычно, рекомендуют использовать исключения только в нештатных ситуациях, ни в коем случае не применяя их для управления логикой исполнения. И этому есть разумные объяснения. Исключения очень хороши во первых тем, что позволяют снять с кода бросающего исключение ответственность по его обработке, давая возможность среагировать на ошибку коду, который знает как это сделать. Исключения так же хороши тем, что в отличие от подхода с возвратом кода ошибок их невозможно игнорировать (это как раз к тому, почему они хороши для обработки нештатных ситуаций). Плюс вы получаете преимущества связанные с уменьшением дублирования и улучшения читаемости кода обработки ошибок.
Если же использовать исключения для организации логики, то в этом они подобны goto, если даже не хуже. Из одного места кода вы вдруг переходите в другое. Повсеместное использование исключений разрушает код. Конечно, грань очень тонкая. Неверные данные, введённые пользователем это штатная или не штатная ситуация? Это зависит от точки зрения разработчика и уровня кода работающего с данными (скажем, на уровне представления неверно введённые данные это нормально, если же вы пытаетесь сохранить объект с этими неверными данными в базу то наверное уже нет.)
В вашем случае без исключений вполне можно было бы обойтись. Было бы вполне достаточно вернуть из функции валидации объект с данными об ошибках. Я не вижу, как в этом конкретном примере полезны исключения.
Указателей в php нет :)
Вы понимаете смысл того что говорит Кнут, и другие известные программисты?
Они не утверждают, что программы должны быть медленными, они не говорят, что оптимизация не нужна или бесполезна.
Все эти цитаты о том, как её правильно проводить.
Нет смысла тратить усилия, и разрушать код (а оптимизация на уровне кода неминуемо делает его менее понятным) по всему проекту, если это даёт лишь жалкие десятые процентов прироста. Надо искать корень проблем с производительностью.
Конечно, можно постоянно заниматься оптимизацией в качестве интеллектуального упражнения, как предлагаете вы. Но в профессиональной разработке программ это не серьезно (пожалейте ваших коллег по команде, и тех кто будет разбираться в коде после вас).
Надо обязательно рассказать и о других принципах: разделении интерфейсов, открытости-закрытости и т.д. (Ну вы знает, всё как в книжке у дяди Боба (Мартина)).
Ещё неплохо было бы написать о Domain Driven development.
Конечно, обязательно изложение паттернов проектирования. Возможно, хорошим вариантом будет рассказать о них параллельно с изложением принципов ООП, показав тем самым, как эти принципы отражаются в них и работают на практике.
В рефакторинге надо не забыть рассказать о важности юнит тестов (и может быть о TDD тогда уж), перечислить основные code smells.
В общем, надо наставить студентов на истинный путь. Убедить, что класс программиста определяется читаемостью его кода, что надо писать насколько это возможно понятный самодокументированный код и стремится к его совершенству :)
В итоге, учитывая ограниченный объём пособия, получится вот такой вот евангелизм на тему аджайл технологий. Главное чтобы он дал толчок к профессиональному развитию тем, кто действительно хочет стать хорошим разработчиком.
Ввести табуляцию в синтаксис - это на самом деле очень здравая идея, ведь и так все блоки кода обычно форматируются табуляцией, так зачем плодить лишние синтаксические элементы.
А как кстати сделать цикл, повторяющийся очень большое число раз?
Ведь, как я понял range возвращает массив, при большом количестве очень длинных циклов это будет не лучшим образом сказываться на использовании памяти.
А общем, код легко читается.