тогда это не интересно — весь смысл серверных ридеров в том, что все вычислительные затраты ложатся на сервер, а тут эти затраты походу завязываются на клиентов. Интересен именно сервер, которые всю вычислительную работу делает у себя, отдавая клиенту только подготовленный контент.
Все очень просто: слово devblog это сокращенное название блога дев сайт незензурного содержания, а blackberry слово содержащее негатив и коррелирует с контрабандой черной икры… Фильтр работает в полуавтоматическом режиме. Проще на всякий случай залочить автоматом — разлочить всегда успеется.
Согласен, когда вспомогательный класс расположен совместно где-то в файле с другим классом обнаружить его сложнее. И в случае его обособленного использования — штатный автозагрузчик будет бессилен. Для решения этой проблемы потребуется дополнительная логика автозагрузчику или полная информация обо всех классах в проекте либо, да — использовать правило: один класс один файл.
Речь идет не о том чтобы держать все в одном файле, а том, что прямой маппинг имен не позволяет держать несколько классов в одном файле. Это на мой взгляд не всегда удобно, особенно при большом числе мелких вспомогательных классов.
Возможен такой хинт: так как такое бывает не часто, то в случае ошибки автозагрузчик открывает все не открытые модули для данного уровня пространств имен.
насчет мейна после размышлений — в общем оно конечно хорошо, но будет жутко тормозить при проверках. Лучше тогда поменять имя главного класса пакета-компоненты на Main. В этом случае дублирование снимается и все ок.
Тавтология — да, поспорить сложно. Но в чем двусмысленность?
На мой взгляд двусмысленность или неоднозначность в том, что сложно отличить имя класса от части namespace Лично меня это запутывает. Когда вложенность namespace большая — приходится задаваться всякий раз вопросом: а нет ли такого класса на данном уровне namespace?
Вы правы. Справедливое замечание. Об полной записи класса, зависимостях и наглядности как-то не подумал. Выработалась привычка писать в основном такое клише:
...
use something\somewhere;
...
$ofoo = new somewhere\Foo();
$obar = new somewhere\Bar();
$obaz = new somewhere\baz\Baz();
Согласен, в таком коде несколько сложнее будет отследить явно имя класса. Но это можно легко компенсировать тегами комментариями на диалекте phpdoc/doxygen. Но так более компактно и проще разрешить конфликты имен.
Особенно когда в директории Component достаточно много вложенных директорий (а так и есть), решение вынести из каждой по одному файлу не выглядит особо рациональным.
В общем-то я за то, чтобы все части компонента располагались в отдельной папке, но без тавтологии. Просто может быть можно и оставить маппинг полных имен на структуру каталогов, но имена частей делать более компактными и повторно используемыми.
а «менеджеру пакетов», в роли которого частенько выступает человек, которому удобно «пакет — каталог». Хотя, можно было бы позаимствовать концепцию загрузки из python (вроде) и избежать дублирования с помощью файла с предопределенным именем. То есть класс Symfony\Component\PropertyAccess хранился бы в Symfony/Component/PropertyAccess/__main.php,
Собственно менджера пакетов как раз и не хватает. Вы правильно заметили, что в качестве оного выступает человек. В симфони и PSR, выбран на мой взгляд компромисс между human readable format и программный формат. Но большая вложенность это явный перегиб в сторону программного формата нежели человеко-читаемого + тавтология. Насчет питоновской концепции здравая мысль. Только такое в общем-то уже есть. Называется по другому: вместо __main.php обычно autoload.php, расположенный где-то в известном месте.
К идее «один класс или интерфейс — один файл c однозначным соответствием имен» я пришёл ещё во времена PHP4.
Вы не одиноки в этом — аналогично. Но со временем стало раздражать по каждому чиху создавать отдельный модуль. Нет все держать в одном модуле большее зло — речь идет о разумном компромиссе. С появлением autoload в самом php и spl_autoload все значительно упростилось.
Длинный список require_once 'module_class' с явными зависимостями для каждого используемого класса каждого используемого модуля мне показался более предпочтительный в плане поддержки чем по несколько require_once 'module_submodule' без явного соответствия submodule и имен классов. Хотя, с помощью питоновской системы и это, наверное, можно было решить.
Никаких *_once это только запутывает и усложняет на мой взгляд — все гораздо проще и оптимальнее через одну точку входа на загрузку через spl_autoload.
В идеальном случае include|require сосредоточены только в модулях автозагрузки. Другими словами в прикладном коде нет инклюдов. Это создает некоторую проблему по загрузке чисто функций и просто кода не привязанного к классам, но это решаемо.
Штатный автозагрузчик по маппингу имен классов делает свою работу относительно хорошо. Но за это приходится платить дублированием имен и довольно приличной вложенностью папок. Это больше похоже на машиночитаемый формат. Кстати, размышляя на эту тему увидел интересную аллегорию с классами и ЧПУ. Что-то в этом есть…
Что же такого отвлекающего и утомительного, особенно при наличии автозагрузчика? Создать файл? Скорее уж утомительно потом лазать по файлу и искать где же нужный класс
Значительно более отвлекает в сравнении, когда все в одном файле. Другой вопрос, что файл может быстро расти, но это стимулирует делать модули компактными.
На мой взгляд, зачем без особой необходимости создавать еще лишние сущности — лучше держать все рядом. Так нагляднее и проще. Особенно это актуально при непосредственной разработке компонента. Да, согласен, что как только классов становится много — такой модуль придется «расшивать», но это обычно уже характерные архитектурные проблемы и антипаттерны. Типа класс слишком много на себя берет. Кстати так легче отследить «точку перегиба», когда число сущностей необоснованно растет.
Насчет «искать где нужный класс» — в общем да, по имени модуля найти класс относительно легко, если не принимать во внимание вложенности папок (нужные классы живут в дремучих лесах). Но обычно это проблема качественной диагностики обработчиком ошибок: имя модуля, класс, строка, ошибка. Когда это работает правильно — локализовать ошибку легко. Есть еще удобное средство поиска git grep, git ls-files рекомендую к использованию.
Существуют еще версии:
— это n-ая итерация и мы играем в игру «из какого же файла выносить»;
— эта библиотека лежит в репозитории и мы делаем весьма забавный коммит (или еще смешнее, пулл реквест, а если не примут, тогда форк).
с этого места не совсем понятно о чем речь — можно более развернуто?
Оно понятно что это дань автозагрузчику классов, вычисляющиего по сигнатуре полного имени класса его точный путь, но иногда бывает очень удобно разместить те-же интерфейсные классы прямо в том же файле, где объявлен класс. На практике получается, что в таком модуле могут содержаться (или логично или так хочется) несколько связанных классов Создавать еще один файл ради того чобы туда поместить интерфейс или подкласс Exception занятие утомительное и отвлекающее. Весь компонент может уместиться в одном модуле, если он получается не более 600-700 строк кода.
Решить проблему загрузки классов можно явным указанием статического списка классов, которые в свою очередь при старте будет добавлен к автозагрузчику классов. Есть несколько утилит, генерирующий модуль автолоад всех зависимых классов.
мне хоть и нравится тенденция гугла и ведроида но что-то отпугивает в плане вседозволенности вендоров на устройстве, навязывание сомнительных услуг и сервисов — яндекс-барщиной, майлру(агент)гвардщино попахивает… С нетерпением ждем убунту-фона да и те настораживают своими нововведениями…
Да и java на мобильных платформах как-то не вдохновляет, хотя и не являюсь ее ненавитником. Живет себе и пущай живет…
Насчет Nexus вроде что-то действительно проскакивало и не раз. Но моторола это легенда уже наверное.
Мне конечно симфони интересна, но вот это совсем уж круче вареных яиц:
use Symfony\Component\PropertyAccess\PropertyAccess;
Это так стандарты PSR-N советуют? Нафиг нафиг такие стандарты. Какая двухсмысленноть и тавтоглогия. Сдается мне все это как хомут следования сомнительным стандартам.
надо было хотя-бы так написать:
namespace symfony\сomponent;
class PropertyAccess
{
...
}
а потом:
use symfony\component;
...
component\PropertyAccess
Подумалось: рынок перенасыщен технологиями — настает время для зарождения технологий обучения… Возможность быстрого изучения/освоения технологии весьма актуальна. Даже кто все знает полезно иногда «прокачать скиллы». Главное чтобы там небыло флэша.
не являюсь большим экспертом по производителям телефонов и в особенности моторол, но считаю, что мотороллеры всегда были новаторами рынка. Хочется просто нормльный аппарат без зондов и чтобы работал с линуксом без проблем и чтобы можно было лего писать программы для него на каком угодно языке…
Когда-то гуглил тему насчет дружелюбности аппаратов с линукс и по всем результатам получилось что мотороллы самое меньшее зло. Поэтому у меня и теплится надежда, что они предложат что-то рынку адекватное. Но сейчас собственно телефоны даже не интересны особо никому — все гонятся за прибылью от планшетников и смартофонов.
Спасибо за интересную информацию по поводу привязки — не знал о таких проблемах у мотороллеров.
ну дык остается тогда совсем небольшой выбор… От моторолы поке еще в надежде и жду интересных решений. На мой взгляд они пока еще не определились со стратегией на новых веяниях рынка или пашут только на оборонку — так что, если не загнутся, то может выдадут качественное решение
Меня интересуют подобные инструменты как персональная база знаний. С практической точки зрения чтобы это добро не тормозило, работало без флэша, использовало свежие и здравые идеи HTML5, работало с популярными браузерами (chromium, firefox) и под линукс и открытым кодом.
В основном меня интересует удобный сервис закладок и автоматическая разумная расстановка тэгов с поддержкой разных языков при добавлении закладок. Экспорт/импорт в популярные сервисы хранения закладок. Поддержка ssl/https.
Касаемо поддержки браузеров это могут быть расширения или удобные букмарклеты. Для chromium расширение не интересно.
Особенно интересует чистота технологий на предмет остутствия флэша. Как-то заходил на их сайт: там демки выложены во флеше — это не камильфо как-то.
то что Samsung платиновый участник www.linuxfoundation.org/about/members спонсирования ядра линукс это замечательно. Но это еще ничего не значит хотя и опережает гугл по спонсорству судя по данным фонда.
Просто, когда имел дело с их телефоном не последней модели для выгрзуки фоток пришлось ставить кучу софта непонятного назначения — теперь выработался стойкий рефлекс. Лучше уж какую-ниюудь мотороллу…
Согласен, когда вспомогательный класс расположен совместно где-то в файле с другим классом обнаружить его сложнее. И в случае его обособленного использования — штатный автозагрузчик будет бессилен. Для решения этой проблемы потребуется дополнительная логика автозагрузчику или полная информация обо всех классах в проекте либо, да — использовать правило: один класс один файл.
Речь идет не о том чтобы держать все в одном файле, а том, что прямой маппинг имен не позволяет держать несколько классов в одном файле. Это на мой взгляд не всегда удобно, особенно при большом числе мелких вспомогательных классов.
Возможен такой хинт: так как такое бывает не часто, то в случае ошибки автозагрузчик открывает все не открытые модули для данного уровня пространств имен.
На мой взгляд двусмысленность или неоднозначность в том, что сложно отличить имя класса от части namespace Лично меня это запутывает. Когда вложенность namespace большая — приходится задаваться всякий раз вопросом: а нет ли такого класса на данном уровне namespace?
Вы правы. Справедливое замечание. Об полной записи класса, зависимостях и наглядности как-то не подумал. Выработалась привычка писать в основном такое клише:
Согласен, в таком коде несколько сложнее будет отследить явно имя класса. Но это можно легко компенсировать тегами комментариями на диалекте phpdoc/doxygen. Но так более компактно и проще разрешить конфликты имен.
В общем-то я за то, чтобы все части компонента располагались в отдельной папке, но без тавтологии. Просто может быть можно и оставить маппинг полных имен на структуру каталогов, но имена частей делать более компактными и повторно используемыми.
Например типа такой структуры: pear2.php.net/PEAR2_Pyrus_Developer/files
Там более прозрачная структура, хотя и большая вложенность присутствует.
Собственно менджера пакетов как раз и не хватает. Вы правильно заметили, что в качестве оного выступает человек. В симфони и PSR, выбран на мой взгляд компромисс между human readable format и программный формат. Но большая вложенность это явный перегиб в сторону программного формата нежели человеко-читаемого + тавтология. Насчет питоновской концепции здравая мысль. Только такое в общем-то уже есть. Называется по другому: вместо __main.php обычно autoload.php, расположенный где-то в известном месте.
Вы не одиноки в этом — аналогично. Но со временем стало раздражать по каждому чиху создавать отдельный модуль. Нет все держать в одном модуле большее зло — речь идет о разумном компромиссе. С появлением autoload в самом php и spl_autoload все значительно упростилось.
Никаких *_once это только запутывает и усложняет на мой взгляд — все гораздо проще и оптимальнее через одну точку входа на загрузку через spl_autoload.
В идеальном случае include|require сосредоточены только в модулях автозагрузки. Другими словами в прикладном коде нет инклюдов. Это создает некоторую проблему по загрузке чисто функций и просто кода не привязанного к классам, но это решаемо.
Значительно более отвлекает в сравнении, когда все в одном файле. Другой вопрос, что файл может быстро расти, но это стимулирует делать модули компактными.
На мой взгляд, зачем без особой необходимости создавать еще лишние сущности — лучше держать все рядом. Так нагляднее и проще. Особенно это актуально при непосредственной разработке компонента. Да, согласен, что как только классов становится много — такой модуль придется «расшивать», но это обычно уже характерные архитектурные проблемы и антипаттерны. Типа класс слишком много на себя берет. Кстати так легче отследить «точку перегиба», когда число сущностей необоснованно растет.
Насчет «искать где нужный класс» — в общем да, по имени модуля найти класс относительно легко, если не принимать во внимание вложенности папок (нужные классы живут в дремучих лесах). Но обычно это проблема качественной диагностики обработчиком ошибок: имя модуля, класс, строка, ошибка. Когда это работает правильно — локализовать ошибку легко. Есть еще удобное средство поиска git grep, git ls-files рекомендую к использованию.
с этого места не совсем понятно о чем речь — можно более развернуто?
Решить проблему загрузки классов можно явным указанием статического списка классов, которые в свою очередь при старте будет добавлен к автозагрузчику классов. Есть несколько утилит, генерирующий модуль автолоад всех зависимых классов.
Да и java на мобильных платформах как-то не вдохновляет, хотя и не являюсь ее ненавитником. Живет себе и пущай живет…
Насчет Nexus вроде что-то действительно проскакивало и не раз. Но моторола это легенда уже наверное.
Это так стандарты PSR-N советуют? Нафиг нафиг такие стандарты. Какая двухсмысленноть и тавтоглогия. Сдается мне все это как хомут следования сомнительным стандартам.
надо было хотя-бы так написать:
а потом:
Спасибо за статью и ссылки.
Когда-то гуглил тему насчет дружелюбности аппаратов с линукс и по всем результатам получилось что мотороллы самое меньшее зло. Поэтому у меня и теплится надежда, что они предложат что-то рынку адекватное. Но сейчас собственно телефоны даже не интересны особо никому — все гонятся за прибылью от планшетников и смартофонов.
Спасибо за интересную информацию по поводу привязки — не знал о таких проблемах у мотороллеров.
В основном меня интересует удобный сервис закладок и автоматическая разумная расстановка тэгов с поддержкой разных языков при добавлении закладок. Экспорт/импорт в популярные сервисы хранения закладок. Поддержка ssl/https.
Касаемо поддержки браузеров это могут быть расширения или удобные букмарклеты. Для chromium расширение не интересно.
Особенно интересует чистота технологий на предмет остутствия флэша. Как-то заходил на их сайт: там демки выложены во флеше — это не камильфо как-то.
Просто, когда имел дело с их телефоном не последней модели для выгрзуки фоток пришлось ставить кучу софта непонятного назначения — теперь выработался стойкий рефлекс. Лучше уж какую-ниюудь мотороллу…