Я писал, что я отказался от варианта расширений в принципе, так как обрабатывать данные внутри него — это довольно сложно, для этого нужен уже не php разработчик, а c++ программист. И тут встает вопрос — а оно надо? Может просто эту часть проекта на c++ переписать и всё будет очень быстро.
По сути вы не библиотеку для всех пишите (имею ввиду php-pg, php-redis и подобные), а я так понимаю часть бизнес логики. Вот как раз это, думаю, просто надо писать отдельно от php кода.
Да, но вот я только что подумал о том, что я не пробовал сишный класс как единственное свойство моего «бизнес» класса сделать и там всю инфу хранить — так может и отрулило бы. Правда это какой-то антипаттерн получается — объект для простого хранения инфы.
У меня задача была уменьшить потребление памяти программы. Она уходила именно на большое кол-во объектов > 5 млн. со свойствами и пр. (предлагаю не обсуждать зачем мне это надо было, это сейчас не важно). Так вот я реализовал простой класс-убийцу класс-заменитель на C++ как extension для php и всё было круто — память почти не кушалась, по сравнению с php, но вот уже бизнес-логику в классы было добавит сложнее. И тут я подумал — а не сделать ли мне наследника этого класса, не переобъявляя свойства cpp-класса? Сделал — и память тут же начала кушаться как раньше.
Следующая проблема — поддержка таких классов. Много знаете программистов которые смогут разобраться в этом коде?
И тут я понял — может просто стоит изолировать такие места в отдельные подпрограммы на cpp, если уж так важна скорость? На этом я и остановился. Но вообще вопрос интересный, так-то я не против ускорить узкое место, просто понимать стоит ли оно того.
> С недавних пор да. Как использую — подключаю в PHP ini. =) Для чего — для увеличения производительности.
Ну вы мне не ответ написали ) Про php.ini и пр. я бы и в документации прочитал сам, если бы не знал. «для увеличения производительности» — это вроде как всем и так уже всем вроде понято. Я тут не для холиваров и пр. Интересно суть проблемы узнать. Под вопросом «как и где» я имел ввиду реальные примеры. Просто я как-то раз думал о внедрении, но тут проблема тестирования встала, да и просто надежности.
Хочется узнать для каких именно задач вы именно вы используете.
Не знаю будет ли следующее в тему, но скажу. Я вот совершенно в очередной раз перечитывал мануал недавно наткнулся на «SplDoublyLinkedList» в структуру этого типа можно делать push объектов (это важно!) раза в 2,5 — 3 быстрее, чем в стандартные массивы.
Согласен, просто как бы это двусмысленно не звучало — надо знать меру. Конечно, на мой взгляд, не все надо делать объектами просто потому, что большие дяди так сказали. Хотя, безусловно, дядей надо слушать и много читать, но и своя голова на плечах должна быть.
На мой взгляд не очень хорошо, что тесты будут «раскиданы» по коду, т.е., например, в случае с phpunit их можно сложить в отдельную папочку, а в вашем случае все равно будут phpunit тесты в отдельной папке, плюс тесты в комментариях.
Вы сейчас пытаетесь разжечь холивар? Не понимаю, зачем все постоянно ругают php.
Несомненно, есть языки лучше и хуже, почти все преследуют свою цель. Если бы php был бы таким плохим — на нем бы не писали. Людям тут помогать надо, а не говорить, что они — недопрограммисты.
> Стандарт для современных регулярных выражений — это Perl-совместимые. Почему они не поддерживались при проектировании языка — непонятно, но те самые 90% программистов об этом наверно и не подозревали.
Согласен, что всегда надо разрабатывать по принципу «наименьшего удивления». Т.е. делать именно ожидаемое поведение системы/модулей/классов/функций и т.д.
Товарищи минусующие — пишите за что хотя бы за что, а вообще говоря я подразумевал, что js код конечно не пользователь писать должен, а естественно разработчик.
> Пользователь страницы этого не может.
Ну я имел ввиду, что именно разработчик функционал должен добавить.
> Технически да, это возможно делать, но вот отчего разрабы ленятся такое добавлять в свой JS,
Ну надо быть честными — программисты часто ленятся делать полезные людям вещи.
Могу сказать, что у Яндекса он был в своё время и они от него отказались, про Google не могу сказать точно, но вроде тоже был где-то кроме Google Images, как раз в последнем скролл вполне уместен, как и писал hVostt про Tumblr — по тем же причинам.
Могу сказать одно — по мне его можно использовать, когда у вас не более 2-3-х страниц подгружается, иначе, действительно, превращается во что-то непонятное. И, конечно, тема холиварная.
Как решение — можно где-нибудь в углу показывать подсказку — на какой странице пользователь сейчас и сколько всего. Как-то так.
По сути вы не библиотеку для всех пишите (имею ввиду php-pg, php-redis и подобные), а я так понимаю часть бизнес логики. Вот как раз это, думаю, просто надо писать отдельно от php кода.
класс-убийцукласс-заменитель на C++ как extension для php и всё было круто — память почти не кушалась, по сравнению с php, но вот уже бизнес-логику в классы было добавит сложнее. И тут я подумал — а не сделать ли мне наследника этого класса, не переобъявляя свойства cpp-класса? Сделал — и память тут же начала кушаться как раньше.Следующая проблема — поддержка таких классов. Много знаете программистов которые смогут разобраться в этом коде?
И тут я понял — может просто стоит изолировать такие места в отдельные подпрограммы на cpp, если уж так важна скорость? На этом я и остановился. Но вообще вопрос интересный, так-то я не против ускорить узкое место, просто понимать стоит ли оно того.
Ну вы мне не ответ написали ) Про php.ini и пр. я бы и в документации прочитал сам, если бы не знал. «для увеличения производительности» — это вроде как всем и так уже всем вроде понято. Я тут не для холиваров и пр. Интересно суть проблемы узнать. Под вопросом «как и где» я имел ввиду реальные примеры. Просто я как-то раз думал о внедрении, но тут проблема тестирования встала, да и просто надежности.
Хочется узнать для каких именно задач вы именно вы используете.
Не знаю будет ли следующее в тему, но скажу. Я вот совершенно в очередной раз перечитывал мануал недавно наткнулся на «SplDoublyLinkedList» в структуру этого типа можно делать push объектов (это важно!) раза в 2,5 — 3 быстрее, чем в стандартные массивы.
Несомненно, есть языки лучше и хуже, почти все преследуют свою цель. Если бы php был бы таким плохим — на нем бы не писали. Людям тут помогать надо, а не говорить, что они — недопрограммисты.
Согласен, что всегда надо разрабатывать по принципу «наименьшего удивления». Т.е. делать именно ожидаемое поведение системы/модулей/классов/функций и т.д.
Ну я имел ввиду, что именно разработчик функционал должен добавить.
> Технически да, это возможно делать, но вот отчего разрабы ленятся такое добавлять в свой JS,
Ну надо быть честными — программисты часто ленятся делать полезные людям вещи.
Могу сказать одно — по мне его можно использовать, когда у вас не более 2-3-х страниц подгружается, иначе, действительно, превращается во что-то непонятное. И, конечно, тема холиварная.
Как решение — можно где-нибудь в углу показывать подсказку — на какой странице пользователь сейчас и сколько всего. Как-то так.