Примет тут метод? Я о том что нужно переименовать СВОЙСТВО! А у вас для ВСЕХ свойств один и тот же метод setProperty, и ни одна IDE вам не моможет, но самая забава начнется когда кто-то сделает $SomeObject->setProperty($name)… рассказывать как весело бывает разбираться в том, что скрывается за $name, думаю не нужно?
> $SomeObject->setProperty('xxx');
Он читабельнее до того момента пока вам не приходится изменять названия свойств (при изменении модели таблицы, например) и вот тут то с этими setProperty начинается большая ж… а, поверьте, найти и изменить ->xxx гораздо проще и быстрее (хотя бы в силу того, что вариантов для поиска меньше). + для ->xxx можно использовать phpdoc тег @property, что сильно облегчает вспоминание назначения свойства.
> А что делать, если обязательным условием для целостности объекта является наличие 20 членов?
ИМХО, стоит задуматься о рефакторинге — не могу представить ситуацию когда классу нужны 20 обязательных параметров. В большинстве случаев большая их часть будет всегда принимать одинаковые значения => их можно объявить в самом классе и далее "… оставить только основные ...." (см. предыдущий комментарий).
> Или если в конструктор передается строка из базы данных?
Если в конструктор передается строка из БД, то, в подавляющем большинстве случаев, она будет уже или в виде ассоциативного массива или в виде объекта. И в том и в другом случае будет всего 1 параметр.
Извините, но это глупо передавать 20 параметров в конструктор, гораздо логичнее и лучше оставить только основные (3-4-5 штук), а все остальные изменять через setProperty('name', 'value') или setProperties(array()) и в этом случае очень удобно использовать константы класса (о чем я ниже писал). В качестве примера можно привести класс PDO и его метод PDO::setAttribute().
Странно, почему никто не упомянул о том, что в этом случае в качестве ключей массива можно использовать константы класса — нет необходимости смотреть на код самого класса/метода, т.к. все нормальные IDE умеют показывать как сами константы (сложно опечататься) так и их phpdoc (сразу вспоминаем что это за параметр).
Этот подход особенно удобен когда какой-любо класс требует для своей работы более ~десятка параметров (редко, но бывает).
> Я пробовал писать код с тестоми и у меня это получалось медленней.
Ну тут ничего удивительно то нет, выигрыш получается за счет экономии времени на отладку проекта при его доработке и/или рефакторинге (обусловлен он тем, что вам нет необходимости сидеть и с дебагером искать в чем же эта ё… я ошибка — юнит тест уже указывает на неё).
Хм, как не подумал о этом. Вопрос был задан безотносительно данного топика (собственно, этот топик на данный момент единственное место где могу задать подобный вопрос :().
За что минусуют? ActiveRecord не всегда удобно использовать да и кроме него есть еще несколько более сложных, но и более удобных шаблонов (data access object, table data gateway, row data gateway, data mapper и т.д.). Было бы интересно увидеть их реализацию.
В этом то и проблема — mysql напрямую далеко не на всех серверах способна переварить подобный запрос (размер которого может быть несколько сотен мегабайт) => созданный дамп без дампера тяжело будет залить куда либо. Да и идеологически неверно разбивать запрос и заливать его кусками.
Надеюсь, когда нибудь появиться настройка, позволяющая генерировать множественные INSERT-ы.
Вам в любом случае потребуется один раз прочитать все символы, вот только сейчас это гарантированно происходит один раз, а в случае регекспов большинство конструкций потребуют многократного прохода. Поэтому сказать что регекспы будут быстрее нельзя. Хотя, было интересно посмотреть на регекспы реализующие спецификацию «на 1310 страницах».
> FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло.
Почему был? Он и сейчас, ИМХО, хорош. Настолько хорош, что не пытается установить в хром неудаляемый плагин для собственного обновления ;)
> UI делают на XML
Чем вас XML не устраивает?
> то Pdf просмотрщик на яваскрипте.
Разве не здорово, что то, что раньше могло быть реализовано на C/C++, сейчас можно реализовать на js?
Во-первых, даже побайтное чтение файла в JS скрипте вовсе не означает что он действительно читается по одному байту. Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде. И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой, который, кроме всего прочего, еще и автоматически обеспечивает проверку этой структуры, регекспы об этой структуре ничего не знают и знать не могут, уже одно только это делает их непригодными для разбора, добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.
Вы все еще уверены что разработчики были не правы?
> Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.
Вообще то любая регулярка в конечном итоге сводится к конечному автомату, кроме того, она точно также прочитает весь документ по байтику, а если учесть стандартные ограничение регулярных выражений, то становится понятно, что никто в здравом уме не станет реализовывать на них ни один серьезный парсер. Поэтому «разбор машиной состояний» только в вашем представлении является «самым медленным способом парсинга».
Думаю, просить вас привести список существующих в природе способов парсинга файлов бесполезно?
А это смотря как спроектировать :)
Если создать объект типа BankAccount, то это будет 1 метод с 2 параметрами:
$a1 = new BankAccount(/*… */);
$a2 = new BankAccount(/*… */);
$a1->sendTo($a2, '200000.99');
Сам расчетный счет можно получать из объекта Bank (т.к. часть реквизитов при переводе относится к банку) и т.д.
Вопрос только в том, нужна ли в данном случае столь подробная структура классов или можно обойтись одним методом?
Он читабельнее до того момента пока вам не приходится изменять названия свойств (при изменении модели таблицы, например) и вот тут то с этими setProperty начинается большая ж… а, поверьте, найти и изменить ->xxx гораздо проще и быстрее (хотя бы в силу того, что вариантов для поиска меньше). + для ->xxx можно использовать phpdoc тег @property, что сильно облегчает вспоминание назначения свойства.
ИМХО, стоит задуматься о рефакторинге — не могу представить ситуацию когда классу нужны 20 обязательных параметров. В большинстве случаев большая их часть будет всегда принимать одинаковые значения => их можно объявить в самом классе и далее "… оставить только основные ...." (см. предыдущий комментарий).
> Или если в конструктор передается строка из базы данных?
Если в конструктор передается строка из БД, то, в подавляющем большинстве случаев, она будет уже или в виде ассоциативного массива или в виде объекта. И в том и в другом случае будет всего 1 параметр.
Странно, почему никто не упомянул о том, что в этом случае в качестве ключей массива можно использовать константы класса — нет необходимости смотреть на код самого класса/метода, т.к. все нормальные IDE умеют показывать как сами константы (сложно опечататься) так и их phpdoc (сразу вспоминаем что это за параметр).
Этот подход особенно удобен когда какой-любо класс требует для своей работы более ~десятка параметров (редко, но бывает).
Ну тут ничего удивительно то нет, выигрыш получается за счет экономии времени на отладку проекта при его доработке и/или рефакторинге (обусловлен он тем, что вам нет необходимости сидеть и с дебагером искать в чем же эта ё… я ошибка — юнит тест уже указывает на неё).
(приелось и хочется чего то более экзотического)
В этом то и проблема — mysql напрямую далеко не на всех серверах способна переварить подобный запрос (размер которого может быть несколько сотен мегабайт) => созданный дамп без дампера тяжело будет залить куда либо. Да и идеологически неверно разбивать запрос и заливать его кусками.
Надеюсь, когда нибудь появиться настройка, позволяющая генерировать множественные INSERT-ы.
А то была забавная ситуация когда mysql на сервере не смог скушать созданный дамп по причине нехватки памяти (база где-то гигабайт весила).
Вам в любом случае потребуется один раз прочитать все символы, вот только сейчас это гарантированно происходит один раз, а в случае регекспов большинство конструкций потребуют многократного прохода. Поэтому сказать что регекспы будут быстрее нельзя. Хотя, было интересно посмотреть на регекспы реализующие спецификацию «на 1310 страницах».
> FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло.
Почему был? Он и сейчас, ИМХО, хорош. Настолько хорош, что не пытается установить в хром неудаляемый плагин для собственного обновления ;)
> UI делают на XML
Чем вас XML не устраивает?
> то Pdf просмотрщик на яваскрипте.
Разве не здорово, что то, что раньше могло быть реализовано на C/C++, сейчас можно реализовать на js?
Вы все еще уверены что разработчики были не правы?
Вообще то любая регулярка в конечном итоге сводится к конечному автомату, кроме того, она точно также прочитает весь документ по байтику, а если учесть стандартные ограничение регулярных выражений, то становится понятно, что никто в здравом уме не станет реализовывать на них ни один серьезный парсер. Поэтому «разбор машиной состояний» только в вашем представлении является «самым медленным способом парсинга».
Думаю, просить вас привести список существующих в природе способов парсинга файлов бесполезно?