вот вы очень хорошо сказали, что среда разработки стимулирует писать тот или иной код. Среди пхп программистов многие хвастаются например тем, что пишут в блокноте, ИМХО это недостаток. Недавно Нетбинс (родная IDE Java) анонсировала поддержку PHP не уверен что у них там лучше чем у зенд, но намерен проверить ведь круче чем в NetBeans IDE нигде нет возможностей для рефакторинга. www.netbeans.org/features/php/index.html
к тому что <?=$record['text']?> тоже самое что и <? echo $record['text'];?> а то что вы говорите про ущербность означает что вы не понимаете проблематики буферизации вывода
Есть способ планирования пола: Четность хромосом у сперматозойда определяет пол. Впринципе при искуственном оплодотворении это давно умели делать, но о комерческом применении впервые обэтом слышу
мысль. ну я использую другой костыль: 2 функции assign и eassign но как вы прально сказали это кастыль. Кто-то считает что верстальщик должен везеде корректно расставлять экранирование, но тогда какого черта стока проблем с XSS?
нехорошо вы говорите.
С одной стороны говорите свое мнение, а с другой стороны не хотите аргументировать. Вы поймите, что для зрителя этой странички вы всеголиш зеленый квалратик (ну я индус с перьями, например), так вот если делаете утверждение — проявляйте уважение и аргументируйте и не смайлами пожалуйста.
это голосование показывает степень интереса к шаблонизаторам на хабра сообществе и в такойм констексте ИМХО оно верно
да, вы правы, в таблице наследования класса все есть, учитывая что на нее ссылается каждый экземпляр, то действительно на этапе исполнения нет наклодных расходов вовсе. Что-то я протормозил. Спасибо.
да, вы правы, в таблице наследования класса все есть, учитывая что на нее ссылается каждый экземпляр, то действительно на этапе исполнения нет наклодных расходов вовсе. Что-то я протормозил. Спасибо.
вы не внимательный читатель. я не сравниваю (а что нужно сравнительный анализ сделать технологий и решений?) я рассказываю что на эту тему всегда есть люди, готовые поспорить и привожу топ причин для споров.
пожалуй нужно пояснить почему тут не обойтись просто наследованием от абстрактного класса. Рассмотрим задачку кеширования: например у нас есть Observer который следит за состоянием кеша (задачи прегенерации, задачи логирования и т.д.) и много маленьких разнопрофильных клиентов. Кто-то из клиентов, например, меняет состояние кеша и просит обсервер всех уведомить, что кеш нужно сбросить.
Понятно, что все клиенты отвечают за разные части системы и потому держать в основании дерева их классов ObserverClient не целесообразно.
А так например у нас есть готовый модуль (class A) и мы говорим: теперь эта сущность (наш модуль) тоже научилась работать c нашим сервером кеша (class ACached extends A implements CacheClient)
простите, что примеры немного искуственными кажутся, просто полностью раскрывать задачи занятие не для часу ночи.
Но суть такова: интерфейсы необходимы для стандартизации, а ее нельзя достичь простым наследованием т.к. объекты по своей природе не наследуются от одного родителя (например разнопрофильные сторониие библиотеки).
www.netbeans.org/features/php/index.html
developer.habrahabr.ru/blog/45370/#comment_1158848
кстати в вашей терминалогии можно сказать, что програмный_ слой, ответственный за отображение модели и есть шаблонизатор
С одной стороны говорите свое мнение, а с другой стороны не хотите аргументировать. Вы поймите, что для зрителя этой странички вы всеголиш зеленый квалратик (ну я индус с перьями, например), так вот если делаете утверждение — проявляйте уважение и аргументируйте и не смайлами пожалуйста.
это голосование показывает степень интереса к шаблонизаторам на хабра сообществе и в такойм констексте ИМХО оно верно
нужны, пример:
intarface B…
if ($obj instanceof B){} — заранее не известно что будет жить в $obj
поэтому я и писал
Понятно, что все клиенты отвечают за разные части системы и потому держать в основании дерева их классов ObserverClient не целесообразно.
А так например у нас есть готовый модуль (class A) и мы говорим: теперь эта сущность (наш модуль) тоже научилась работать c нашим сервером кеша (class ACached extends A implements CacheClient)
простите, что примеры немного искуственными кажутся, просто полностью раскрывать задачи занятие не для часу ночи.
Но суть такова: интерфейсы необходимы для стандартизации, а ее нельзя достичь простым наследованием т.к. объекты по своей природе не наследуются от одного родителя (например разнопрофильные сторониие библиотеки).