LoneCat LoneCat

Мне тоже так кажется :) Если в дочернем объекте понадобится использовать getXXX/setXXX — достаточно его просто добавить, если XXX будет совпадать с именем одного из свойств — магический метод просто не будет вызываться, а будет использоваться объявленный метод, если-же вы про то что захочется __call использовать для других целей — то тогда уж и __get/__set возможно тоже :)
Как вариант в дочернем объекте __call можно переобъявить, добавив необходимый функционал и при непопадании вызванного метода в новые условия — вызвать parent::__call($name, $args), который уже проверит вызванный метод на соот-ие getter'ам/setter'ам, и в случае несоответствия будет ругаться Exception'ами.

Захочется — используйте :) __call() срабатывает только для необъявленных методов, как впрочем и __get()/__set().

Вы говорите об обертках для массивов, а я о том что при разделении например модель-вид-контроллер (чем хвастают большинство фреймворков и цмс) — работать с этими массивами предстоит только контроллеру, и даже при отстутсвии этого разделения входные данные неплохо-бы обрабатывать централизовано, если код пестрит if($_GET['param']) { echo $_POST['param']; } то тогда конечно это осложнит замену в нем этих массивов в ручном режиме. Я почему-то считаю это правильным — сначала получить необходимые данные из суперглобальных массивов в переменные, привести к нужным типам, сделать необходимые проверки на правильность их содержимого и уже затем с этими переменными работать.

Уж насколько я люблю распихать все по объектам — но здесь даже я логики не вижу, как раз таки главное отличие $HTTP_***_VARS от $_*** в том что последние — суперглобальные, и доступны в любой области видимости, оборачивать их в зависимые от области видимости объекты — минимум нелогично, да и использоваться они должны при грамотной архитектуре (мы-же о фреймворках говорим?) в специально отведенных для этого местах, и уж Зенд вдруг резко сойдет с ума и переименует эти массивы, безусловно не оставив обратной совместимости (которая по отношению к $HTTP_***_VARS кстати есть), а потом сойдут с ума все хостеры, обновив интерпритатор на эту, веселых расцветок, версию — то заменить пару-тройку переменных в нескольких файлах я думаю не составит такого огромного труда, в современных IDE это можно сделать одной операцией.
С такой позицией тогда уж и каждую используемую встроенную функцию нужно обернуть в пользовательскую или объект, и то, от безумных, с налитыми кровью глазами и кровавой пеной у рта, разработчиков Зенда, удаливших в новой версии интерпритатора все языковые конструкции, начиная от оператора присвоения, заканчивая условными операторами и циклами — это не спасет :)

Видимо кто-то очень не хочет чтобы вы так переутруждали себя работой :)

А у меня на работе как раз гибкий рабочий график, со своими конечно ограничениями, сотрудник должен придти на работу не позже 12 и отработать 8 часов, хотя час-два можно при необходимости перекинуть на другой день или отработать в выходные. Считаю это более чем весомым плюсом своей работы :) ну да контора у нас сравнительно небольшая, и бюрократии в ней пока немного.

Я вообще в математике не силен, но имхо есть такая закономерность:
x = (max — min) * max
соот-но в первом примере это:
x = (5 — 2) * 5 = 3 * 5 = 15
а во втором:
x = (100 — 2) * 100 = 98 * 100 = 9800

О, я помню видел такую фантастическую прелесть :) Массив экранируется через array_map('addslashes', $_POST) и записывается в самого себя… и делается это все на уровне конструктора подключаемых модулей :)
А что самое интересное — модулей на страницу подключается от 1 до 7 штук, итого с учетом отсутствия проверки на magic_quotes к каждой кавычке введенной в поле ввода добавлялось от 3 до 15 слешей :) К трем слешам я еще отнесся с мужеством, а 15 меня реально напугали :)

Ну это по-моему просто специфика рунета, никто в нем не хочет рисковать и браться за какие-либо инновационные проекты, вдруг прогорит? Вдруг не будет пользоваться популярностью? Гораздо проще сделать 15-ый клон известного отечественного проекта, который в свою очередью является 20-ым клоном известного западного, так как зараннее известно что его «пипл хавает», и можно примерно прогнозировать какую копеечку он принесет его владельцу. Новые проекты деляются по принципу «А я тут такой сайт видел!» — ну и понеслась. Шапку сменили, пару ссылок добавили — уже прорыв :)

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

Ну яваскрипт в этом плане исключение, цитата из вики:

Прототипное программированиеПримерами языков программирования, где используется прототипное программирование, являются Self и JavaScript.

• Создание новых объектов через клонирование прототипов.
  Повторное использование кода достигается не через наследование, а с помощью делегирования.
  
  

Соврал что использую рациональный стиль :)

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

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

Тьфу, что-то меня порезало :)

Я пишу в стиле:

Операторы — слитно с условием, фигурные скобки отделены пробелом, и сейчас стараюсь все операторы выносить на новую строку, гораздо удобнее в плане когда нужно что-то добавить, например print_r() какой-нибудь или var_dump(), при отладке и т.п., раньше когда писал слитно — приходилось переформатировать код на несколько строк, добавлять необходимую отладку, а потом когда отладка не нужна — убирать ее и запихивать код обратно в одну строку… в общем лучше уж сразу :)

Фига себе нанооптимизаторы мне карму снесли :) Теперь придется долго реабилитироваться в комментариях опусами о влиянии регистра букв в переменных на производительность скрипта :)

В root мне логи! А я как последний дурак тратил на 0,000003643698 секунды больше, используя третий вариант :(

Симпатично :)

А «итак» может писаться и так, и этак: P

Незнаю, имхо проблема восприятия PHP как языка кухарок — реальная проблема, но она существует уже давно, и я верю что когда-нибудь она сойдет на нет, а вот проблема придумывания велосипедов — проблема надуманная, и на том-же хабре (хотя в меньшей степени) или на каком-нибудь специализированном форуме по PHP — конечно хреновы миллионы непризнанных гениев, хвастающихся своими велосипедами (как в матрице, огромное поле, а там кабачками PHP-девелоперы: P), но это-же все новички, тот кто занимается программированием на PHP давно — давно уже все для себя решил, и имеет собственные готовые програмные решения на любой случай жизни. Мне лично наоборот не нравится тенденция «ухты, а тут все готовенькое, сейчас я это себе в код впихну», если уж и используешь чужой код — то его хотя-бы для начала нужно досконально изучить и понять, и быть в состоянии написать с нуля если не лучше, то хотя-бы также, иначе это не программирование, а собирание конструктора лего. Хотя в чем-то конечно соглашусь, Zend Framework далеко не самое худшее, что есть на PHP, и его хорошо-бы по-больше разрекламировать, чтобы кабачков-велосипедистов впоследствии стало меньше :)

Профайлер еще по-мойму очень вкусная фича, легко и быстро можно найти узкие места проекта.

Хм, а меня наоборот не впечатлил интерфейс Зенда :) Дома установлен 6.01 на эклипсе — юзаю его, и испытываю всяческие эгоистические удовольствия, а на работе 5.51 — тоже вполне себе IDE, но что-то после эклипса не то.

Да они по-моему еще с нового года должны начать переползать... только вот они со мной не согласны :)

А мне лично кажется паттерн DataMapper более удобным нежели различные реализации ORM, все-таки у каждого СУБД есть свои специфичные особенности, которые в общем ORM'е все учесть сложно, и DataMapper в этом плане предоставляет большие возможности для использования сложных, составленных вручную запросов с учетом специфики СУБД. При переходе на другой СУБД DataMapper конечно придется переписывать, но я лично считаю это оправданным, в мелких проектах это не так много работы, а в крупных не так часто меняют СУБД, и там как раз таки очень важна производительность. Ну и при необходимости использования нескольких вариантов хранения информации - DataMapper можно инстанциировать через фабрику.

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

Незнаю, по-моему это не такая непомерная задача - заработать 10$ на домен :) Не думаю что это было мотивацией, пусть не очень мною уважаемого, но тем не менее действительно очень известного и популярного шаблонного движка.

Может там просто баг с шаблонами? :P

Ой, прошу прощения, ошибся :)

Так и я не утверждаю :) В ассемблере этот оператор (его аналог) вполне уместен, и даже более того, является базисом, как например и в некоторых других языках, где без этого оператора невозможно простым и удобным способом реализовать какие-либо конструкции, как например выход из вложенных циклов, и т.п.
Однако в PHP штатных средств для решения таких задач более чем достаточно: функции, исключения и т.п., по аналогии с вашим примером C# - в Java такого или аналогичного оператора - нет, и не предвидится, а ведь нельзя назвать Java языком кухарок, несмотря на то что у них на эмблеме чашка кофе :)

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

Можно пример того, что можно реализовать с помощью GOTO, но нельзя с помощью старого функционала PHP? Насколько я, возможно профан в этом вопросе, представляю - GOTO создан исключительно для того чтобы убивать структуру и читабельность кода, реализуя алгоритмы а-ля:

set_time_limit(0);
ignore_user_abort(true);
$t = microtime(true);
сюды:
goto туды;
туды:
if(connection_aborted()) { goto конец; }
goto сюды;
конец:
$file = fopen('чудо.log', 'a');
fwrite($file, 'Этот юзверь продержался: '.(microtime(true) - $t).' миллисекунд');
fclose($file);

Да, GOTO это конечно феноменальный отжиг :) Ну ничего, тут пофиксить - там поправить... добавить set_goto_handler()/restore_goto_handler(), поддержку новоиспеченных namespace'ов в goto, поддержку объектной модели, а-ля goto array($object, 'label'); ну и т.п. - и всем языкам будет язык :)

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

Честно говоря слабо могу себе представить ситуацию, когда переданные из другого модуля сериализованные данные должны быть сразу отправлены во фронтэнд, обычно такие данные используются для того чтобы изменить поведение конечного модуля, а их для этого соот-но нужно десериализовать.

Для инженера, настоящего темного властелина, конечно-же не имеет значение на чем писать, зачем писать, и как долго :) Сказали писать не на PHP а на Perl'е - потратил месяц на изучение Perl'а, потом еще пол-года на изучение его специфических особенностей, параллельно с отладной написанных на нем нерабочих программ - и вперед, сказали писать на Jav'е - еще пол-года, итого лет за 10 можно заиметь вполне себе многоцелевого программиста, правда PHP он уже к этому времени забудет, потому если вдруг - еще пол-года и... Нанимают-то обычно тех кто готов работать сразу, или подразумевается что инженер-программист при трудоустройстве уже знает все мыслимые и немыслимые языки? Ну тогда уже для конторы не должна иметь значение сумма, которую он запросит за свои услуги :)
Так что имхо профессия-то может и общая, а специализация в ней должна быть своя. Конечно это не отрициет того что теоретически принципы программирования хороший программист должен знать во всем их многообразии, даже если к языку в котором он специализируется они не относятся, но боюсь что страсть к самообразованию не критерий для трудоустройства, потому как ведрами ее мерять проблематично.
А насчет верстки - так уж сложилось что в основном языками программирования называют империтивные языки программирования, а верстка относится к декларативным, где реализация описывается не программистом, а заложена в интерпритатор (в данном случае браузер), и специфика у нее другая, научиться верстать - невелика наука, а знать что при третьем диве слева такой-то браузер дает 8 пикселей справа - на это опять-же нужно время.

Работаю в небольшой конторе на 10 человек, 3 программистов, требования - PHP5 c ООПъектами там всякими, MySQL, JavaScript. Раньше требовали знание HTML/CSS, но после продолжительного нытья на луну, со стороны PHP-программистов, верстку из обязанностей вычеркнули, верстают теперь левые дяди, хотя скорее всего при трудоустройстве знание принципов верстки, при прочих равных, будет неплохим плюсом.

Если говорить в общем - это скорее всего больше зависит от размера конторы, если в маленькой студии, где из персонала один человек (и чтец, и жнец, и на дуде игрец) - требуется вообще все: верстка, программирование, проектирование БД, а еще дизайн, раскрутка и навыки общения с клиентом, то по мере роста конторы обязанности можно (и нужно) распределить, один человек действительно не может быть специалистом во всем одновременно, да и не нужно это, потому как грамотное распределение труда всегда будет давать ощутимый прирост в скорости разработки по сравнению с бюджетными решениями а-ля Вася-Пупкин-All-Included, так как даже если знаешь две каких-либо области на отлично - чтобы переключиться от одной к другой все равно потребуется время.

Да, вообще впринципе наболевшая тема - отделение модели от представления, некоторые даже пытаются реализовать шаблонизатор так, что в нем вообще как факт отсутвуют элементы логики, а вся логика реализуется в коде...
Однако-же код, отвечающий за логику отображения шаблонов - тоже по-моему мнению относится к представлению, и соот-но надо-ли оно, тем более что такое полное разделение зачастую сильно все усложняет?
Отделять шаблоны от кода целиком имеет смысл когда предполагается возможность пользователям добавлять свои шаблоны, однако это спорный наворот, и мало кому нужен.

Да, я как-то тоже не сторонник такого рода систем, да и насчет "все предусмотреть невозможно" - тоже имхо неправильная позиция, можно предусмотреть, если специально этим озадачиться, иже введя например доп.абстракцию, одна лишняя функция/метод, в которую отдельно передаются запрос и параметры оного (с последующей обработкой оных) - уже избавляет от проблем с sql-инъекциями, также можно централизовать обработку данных, пришедших с форм, из адресной строки и т.п., да и вообще проверка наличия того "что нельзя" всегда будет уступать проверке на соответствие тому "что можно".