Я надеюсь, что этот опрос напомнит о данном атрибуте тем верстальщикам, которые о нём забыли, и расскажет тем, кто о нём не знал.
Каюсь, про поведение интерфейсов уже второй месяц не могу закончить статью. Надеюсь в ближайшие несколько дней её допилить.
Шок вызывает неумение конфигурировать среду разработки под конкретные цели и задачи.
Подход «а давайте влупим быструю СУБД и добавим оперативы» без необходимой оптимизации — заведомо провальный. Ну и кривая архитектура приложения заодно. Бывают случаи, когда выгоднее пересмотреть архитектуру и переписать часть логики, чем сразу в омут с головой и смена платформы. Вы бы ещё готовое приложение на .NET предложили переписать.
Если форма простая и все поля упорядочено идут друг за другом, все браузеры ведут себя адекватно. Но стоит на форме появиться какому-то элементу, захватывающему Tab — и вуаля — получаем раздражающий эффект.
Необходимо пояснить. Я, как перфекционист, использую этот атрибут практически в каждой форме, которую мне представляется верстать. Мне приятно, когда поведение формы не перебрасывает меня по нажатию Tab из поля ввода логина на, например, ссылку "Забыли пароль?", а отправляет курсор в поле ввода пароля.
Коллега же мой считает, что данный атрибут морально устарел и его использование не приносит никакой практической пользы.
P.S. Я не говорю, что статическая типизация — плохо. Просто возникают сомнения в адекватности подхода, описанного в статье.
Мне почему-то для контроля типов достаточно PHPDoc и строгой проверки там, где это критично.
Перефразируя: зимой выпадает снег, но это не значит, что это хорошо.
Это просто есть. И раз уж это один из слонов, на которых стоит PHP, то зачем под него засовывать дополнительные костыли?
FYI, это была добрая ирония.
Не хочу вдаваться в холивар. Каждый разрабатывает так, как того требует архитектура и определения «правильно/неправильно» можно давать только относительно каждого проекта/задачи, но не в рамках всего языка.
Инструментарием нужно пользоваться с умом и отказываться от совсем уж извращённых конструкций там, где это совершенно не нужно. Например, скрипт-парсер на 5 процедур значительно выиграет в производительности у скрипта с одним классом на 35 методов и в 3 раза раздутым кодом, а для парсера это очень критично.
Поэтому далеко не во всех проектах «тормоза вызваны не ООП и не обьектами, а кривыми руками программистов». Во многих проектах эти же тормоза вызваны использованием неоптимальных подходов к проектированию архитектуры.
Просто многие девелоперы и не девелоперы вовсе. С понижением порога вхождения говнокода становится всё больше, а мозгов всё меньше.
И воистину противно разговаривать с некоторыми типа-руководителями, которые не отличают программиста от былокодера.
Каюсь, про поведение интерфейсов уже второй месяц не могу закончить статью. Надеюсь в ближайшие несколько дней её допилить.
Подход «а давайте влупим быструю СУБД и добавим оперативы» без необходимой оптимизации — заведомо провальный. Ну и кривая архитектура приложения заодно. Бывают случаи, когда выгоднее пересмотреть архитектуру и переписать часть логики, чем сразу в омут с головой и смена платформы. Вы бы ещё готовое приложение на .NET предложили переписать.
Эээ? о_0
Коллега же мой считает, что данный атрибут морально устарел и его использование не приносит никакой практической пользы.
P.S. Я не говорю, что статическая типизация — плохо. Просто возникают сомнения в адекватности подхода, описанного в статье.
Мне почему-то для контроля типов достаточно PHPDoc и строгой проверки там, где это критично.
Это просто есть. И раз уж это один из слонов, на которых стоит PHP, то зачем под него засовывать дополнительные костыли?
Не хочу вдаваться в холивар. Каждый разрабатывает так, как того требует архитектура и определения «правильно/неправильно» можно давать только относительно каждого проекта/задачи, но не в рамках всего языка.
Это Вам ваши PHP'шники нашептали?
Инструментарием нужно пользоваться с умом и отказываться от совсем уж извращённых конструкций там, где это совершенно не нужно. Например, скрипт-парсер на 5 процедур значительно выиграет в производительности у скрипта с одним классом на 35 методов и в 3 раза раздутым кодом, а для парсера это очень критично.
Поэтому далеко не во всех проектах «тормоза вызваны не ООП и не обьектами, а кривыми руками программистов». Во многих проектах эти же тормоза вызваны использованием неоптимальных подходов к проектированию архитектуры.
И воистину противно разговаривать с некоторыми типа-руководителями, которые не отличают программиста от былокодера.
Офигеть рефакториг и оптимизация за 20 лет.
Иначе можно понять двояко.