Ну не совсем так.
Это всеравно что говорить что ит недало ничего в бугалтерию, как работало все так и работает.
А какже совместнае работа, возможность шарить свои нароботки, повторяеиость результатов, масовость и т.д.
Такой себе оружейный опен сорс.
— с этим могу частично согласиться, так как действтельно все плохо с невалидным html. И это скорей связано с тем что все браузеры/движки разбора html востанавливали его поразному, пока не появился стандарт разбора в html5.
получить их код ТОЧНО как в исходном документе
— вполне возможно, вот только интересно зачем это вам?
Конечно может, учитывая что большенство библиотек трансформируют CSS в XPATH и выполняют его.
Например используя SimpleXml это будет выглядить приблизительно так:
Ну во-первых, он очень прост — так что если вдруг кто то его не знает то лучше потратить час два на изучение
Во-вторых для PHP существует SimpleXML API которое позврляет сдельть все тоже, и так само выразительно, без внешних зависимостей
Иногда просто удивляюсь, насколько перекошенной у меня образование: Про фотонные кристалы (полое волокно) нам читали лекции 10 лет назад, затрагивая методы расчета и перспективные наработки которые тогда могли похвастаться схожими характреристиками и при этом в ит части отставание лет на 10 было…
все дико тормозит при сколь-нибудь серьезном объеме данных, просто для разных технологий он слегка отличается
многие проблемы EAV можна решить материализацией
и говорить что EAV не решает, всеравно что говорить что реляционные базы данных не решают
Вот мне интересно, у вас действительно шифрование узкое место…
Потому что, сейчас выглядит, как будто Вы сделали ненужную работу, усложнили дальнейшую разроботку и поддержку и получили всего навсего 2 ускорение для арм-процесовров
Такое впичетление что нужно было просто показать где на интел процесорах можно получить небольшое большое приемущество по сравнению с соперниками
Статья абсолютно не понравилась. Смесь общих, всем понятных фраз с какимито спорными высказаваниями, как быдто филологу попросили написать реферат об архитектуре.
Ключевым звеном слабосвязной архитектуры является выделение центрального компонента
— это вообще в некакие рамки не вкладываеться…
PS: с другой стороны прекрасная статья, вызавающая кучу неготивних имоцей и желания похоливарить ;)
смысл в большой выразительности языка. Это по сути Extension Methods из С# для скалярных функций
дело ведь не сокращении количества символов, а в однотипности кода.
к тому же, если это станет часть ядра (очень надеюсь) то появиться поддержка в иде и проблем с пониманием не будет
Любое добавление некоторой структуры нужны только для улучшения производительности.
Из моего опыта, лучшие решение с точки зрения чтения — это «вложеные множества». Неплохобы сравнтить с ними
Также, учытывая что Вы используете PostgreSQL, неплохобы попробовать ее встроеные возможности
стало называть синглтон антипаттерном, и создавать сотни абстрактных классов что бы избавиться от пары глобальных.
Вы наверно путаете: разбиение на класы (не в коем случаи абстрактные — это тоже антипатерн) нужен исходя из принципа минимизации ответсвености, а избаление от синглетонов продиктовано необходимость во-первых явго указывать зависимости, и во-вторых уменьшением зависимостей, что очень сложно без первого
еще раз повтою, что в проекте где все изначально спланировано == «небольших», часто такой подход еконимически приемлем
Ситуация не меняется. Нужно использовать паттерны под задачу, нужно решать с их помощью задачу, а не всовывать их везде куда только можно
Сложно не согласиться с утрирждением, что нужно быть умным, а не глупым
Есть ОЧЕНЬ мало ситуаций когда нужен именно DI\IoC. В большинстве случаев достаточно SM
Вот это дествительно спорно
Если предположить что DI\IoC используеться в основном для улучшения тестирования кода и уменьшения связаности/зависимостей на состояние, то станет понятно где они не нужны — в гавно небольших проектах, где покрытие кода тестамы очень низкое, а регресивное тестирование или не проводиться, или занимает небольшое время
Может это Ваш случай, для меня верно обратное
Нужно понимать что ситации бывают разные:
Если вы пишете для конечного заказчика, тогда я с вами согласен
Если же для комьюнити или библиотечный код то ситуация противоположная
Это всеравно что говорить что ит недало ничего в бугалтерию, как работало все так и работает.
А какже совместнае работа, возможность шарить свои нароботки, повторяеиость результатов, масовость и т.д.
Такой себе оружейный опен сорс.
— с этим могу частично согласиться, так как действтельно все плохо с невалидным html. И это скорей связано с тем что все браузеры/движки разбора html востанавливали его поразному, пока не появился стандарт разбора в html5.
— вполне возможно, вот только интересно зачем это вам?
Например используя SimpleXml это будет выглядить приблизительно так:
О чем это вы?
встроенный XML DOM позволяет делать выборки любой сложности и намного гибче CSS
Во-вторых для PHP существует SimpleXML API которое позврляет сдельть все тоже, и так само выразительно, без внешних зависимостей
Имхо, CSS это вообще сплошное недорозумение
многие проблемы EAV можна решить материализацией
и говорить что EAV не решает, всеравно что говорить что реляционные базы данных не решают
Потому что, сейчас выглядит, как будто Вы сделали ненужную работу, усложнили дальнейшую разроботку и поддержку и получили всего навсего 2 ускорение для арм-процесовров
Такое впичетление что нужно было просто показать где на интел процесорах можно получить
небольшоебольшое приемущество по сравнению с соперниками— это вообще в некакие рамки не вкладываеться…
PS: с другой стороны прекрасная статья, вызавающая кучу неготивних имоцей и желания похоливарить ;)
дело ведь не сокращении количества символов, а в однотипности кода.
к тому же, если это станет часть ядра (очень надеюсь) то появиться поддержка в иде и проблем с пониманием не будет
Из моего опыта, лучшие решение с точки зрения чтения — это «вложеные множества». Неплохобы сравнтить с ними
Также, учытывая что Вы используете PostgreSQL, неплохобы попробовать ее встроеные возможности
Особенно обратите внимание на то как реализована сериализация System_Serializer_Dom
Вы наверно путаете: разбиение на класы (не в коем случаи абстрактные — это тоже антипатерн) нужен исходя из принципа минимизации ответсвености, а избаление от синглетонов продиктовано необходимость во-первых явго указывать зависимости, и во-вторых уменьшением зависимостей, что очень сложно без первого
еще раз повтою, что в проекте где все изначально спланировано == «небольших», часто такой подход еконимически приемлем
Сложно не согласиться с утрирждением, что нужно быть умным, а не глупым
Вот это дествительно спорно
Если предположить что DI\IoC используеться в основном для улучшения тестирования кода и уменьшения связаности/зависимостей на состояние, то станет понятно где они не нужны — в
гавнонебольших проектах, где покрытие кода тестамы очень низкое, а регресивное тестирование или не проводиться, или занимает небольшое времяМожет это Ваш случай, для меня верно обратное
Если вы пишете для конечного заказчика, тогда я с вами согласен
Если же для комьюнити или библиотечный код то ситуация противоположная