Если в __get обратиться к полю в $this, то сработает еще один __get. Но дальше PHP как-то распознает, что это будет продолжаться вечно и просто выдает значение поля. Магические методы реализованы крайне странно в PHP)
Повторюсь. В реализации mbstring разность в скорости незначительна настолько, что не заслуживает обсуждения. В вашем примере со строками вы еще более утрируете, на что я отвечать не собираюсь.
В каждом движке уже существуют те или иные допущения, которые делают жизнь проще и требуют процессора. Вы знаете, что метод вызывается в два раза дольше, чем функция в глобальном пространстве? Вы знаете, что константа, объявленная внутри класса резолвится в два раза дольше чем из глобального скопа? Но тем не менее вы используете классы и объекты? Хотя тут разница в разы. Почему же utf8, который работает незначительно медленнее обычных строк, вы считаете чрезмерно тормозящим, несмотря на то, что его вклад в стройность и безошибочность приложения не менее важна, чем при создании хорошей объектно-классовой структуры?
Ни в коем случае не советовал использовать PEAR. PEAR надо знать и уметь с ним обращаться, а использовать или нет — это дело каждого. За все время нормаольно использовать его у меня получилось лишь раз.
Не пытаюсь я вас убедить в чем-либо. В вашем случае это бесполезно. Я лишь высказываю точку зрения для читателей, чтобы они не были дезинформированы вашими рассуждениями.
Накладные расходы в скорости работы встроенных mb* функций по сравнению с не-mb минимальны, я проверял. А размер избыточности данных в процессе передачи вообще не имеет смысл обсуждать. Регулярки в ответственных местах (которые часто выполняются) вообще не стоит использовать ни с cp1251, ни с utf8.
Не в каждом языке есть те же parse_url и parse_str в нативном виде. В не-нативном я и сам напишу. Читайте внимательнее.
Нейспейсы в 5.3 получились крайне сомнительные. Я высказался о них выше. Сам бы я не стал их использовать. Можно лишь надеяться, что в PHP 6 ситуация с неймспейсами изменится к лучшему и резолвинг символов по синтаксису наконец-то заменят на резолвинг по таблице символов. Без этого неймспейсы не имеют смысла.
А вот анонимные функции уже можно использовать вполне.
Экономия незначительна и покрывается сжатием, а вот проблем потенциальных — куча. Я встречал немало библиотек, которые надо было допиливать для cp1251, но без проблем работали в случае с utf8.
create_function — это очень очень плохо, так как PHP-код в таком случае надо записывать строкой, без подсветки синтаксиса, инспекций и тп. Ну и да, я там еще замыкания упомянул.
Пространства имен вещь такая… спорная. Вернее, вообще нейспейсы — очень полезная штука. Но в PHP реализовали их мягко говоря странно. Более-менее удобно если прямо все засунуть в неймспейсы.
В каждом движке уже существуют те или иные допущения, которые делают жизнь проще и требуют процессора. Вы знаете, что метод вызывается в два раза дольше, чем функция в глобальном пространстве? Вы знаете, что константа, объявленная внутри класса резолвится в два раза дольше чем из глобального скопа? Но тем не менее вы используете классы и объекты? Хотя тут разница в разы. Почему же utf8, который работает незначительно медленнее обычных строк, вы считаете чрезмерно тормозящим, несмотря на то, что его вклад в стройность и безошибочность приложения не менее важна, чем при создании хорошей объектно-классовой структуры?
Нейспейсы в 5.3 получились крайне сомнительные. Я высказался о них выше. Сам бы я не стал их использовать. Можно лишь надеяться, что в PHP 6 ситуация с неймспейсами изменится к лучшему и резолвинг символов по синтаксису наконец-то заменят на резолвинг по таблице символов. Без этого неймспейсы не имеют смысла.
А вот анонимные функции уже можно использовать вполне.