> Переписать его было практически невозможно, т.к. он относится к ядру движка. Миллионы страниц Википедии могли полететь в один момент, если бы в каком-то месте нового кода произошла ошибка.
По-моему логичное поведение. Так СУБД приходилось не только парсить запрос, но ещё перед этим канонизировать — а это уже почти тоже самое что и парсинг.
Там берётся существующая(произвольная) функция и каррируется, и получается новая функция. При этом исходная функция не меняется и не знает, что ее каррировали.
Применительно к объектам вижу два пути. Каррируем метод объекта и получаем…
1.… новую функцию;
2.… новый объект с тем же интерфейсом плюс новый метод.
Оба случая должны оперировать произвольным объектом с произвольными методами. При чем так, чтобы ни объект, ни методы не знали о том как с ними обращаются.
В Вашем же подходе, чтобы каррировать метод объекта нужно вмешаться в иерархию наследования и изменить конструктор.
И так вот он класс с каррирующим методом, который и реализует (простите за каламбур) частичное использование метода класса. При этом, создается псевдометод, который и вызывается (опять скаламбурил) магическим методом __call():
Поясните, пожалуйста, в чём здесь заключаются каламбуры?
1. Это диагноз, который называется «echo быстрее, чем print».
2. extract безопаснее Вашего первого способа, там можно указать некоторые настройки. Что касается объектов. Тут нельзя будет использовать extract. Опять же можно всяким мусором заполнить объект. И если все объекты для конфигурирования будут показывать свои свойства всем, то, скажем так, это открывает слишком много секретов, которые должны быть скрыты. Не будет интерфейсов, потому что все свойства будут открыты. Передал один объект он заполнился, передал другой объект, он точно так же заполнился и даже не поперхнулся.
3. Заполнение переменных и объектов будет зависеть не от программы, а от внешних факторов. Т.е. не так как хочет программист, а как повезёт. Передал/не передал, строка/массив. Конечно, можно фильтровать, но объектам не нужны одинаково отфильтрованные данные. Кому-то нужен массив, кому-то числовая строка, а кому-то любая строка подойдёт. Как место_где_распихиываются_данные_по_объектам узнает какому объекту что и в каком формате надо?
1. Можно использовать foreach вместо for
2. А ещё лучше использовать extract
3. А ещё лучше не использовать такой подход в принципе. Можно переписать существующие переменные (свойства). Можно не найти концов при отладке, когда переменные таким неявным способом инициализируются.
PS. register_globals в своё время пилили-пилили и выпилили, а тут прямо-таки «назад в будущее», вернее сказать «вперёд в прошлое».
Не надо демагогии… Сравнивайте язык с языком, а фреймворк с фреймворкам.
Я вижу как идёт спор. Вы противопоставляете разработку на чистом языке разработке на фреймворке, показываете недостатки языка и достоинства фреймворка, сравниваете некоторых разработчиков на одном с некоторыми разработчиками на другом.
Да проблема в том, что понятие инкапсуляции несколько размыто. Но я попробую свою позицию высказать.
От кого скрываем?
От пользователя класса? — нет, в общем случае это невозможно. Пользователь может просто заглянуть в класс и всё посмотреть. А от себя так, вообще, не скроешь.
От кода, который использует класс? — нет, языки часто позволяют обходить эти защитные штуки, допустим, отражениями (рефлексиями). Поэтому нет технической возможности не допускать неправильные использования класса.
Получается, что у пользователя есть возможность обращаться к внутренностям реализации через то или иной манёвр, но это он не делает в повседневном коде. Почему? Потому язык говорит, что так не хорошо делать. И он с ним, как бы, договорился. Если язык не позволяет скрывать что-то в полной мере, то программисты договариваются между собой что скрыто, а что нет.
Ещё можно вспомнить для чего было придумано ООП. Чтобы было проще программировать. Как инкапсуляция позволяет упростить написание кода?
1. Упрощается абстракция. В момент использования класса мы можем «забыть» все его внутренности, и использовать только то, что открыто. Т.е. не надо помнить как какой класс и как именно реализован и что он будет использовать.
2. Локализовать будущие изменения. Изменения того или иного куска кода будет проще, если мы будем знать кто им пользуется. Инкапсуляция позволяет сократить таких пользователей путём расстановки ограничений.
Довольно странный аргумент.
Статья не оформлена как перевод.
А где ссылка на сам парсер?
P.S. Почему пост, а не вопрос?
>>17 year old student
Что Вы хотели этим сказать?
https://bugs.php.net/bug.php?id=54638
Применительно к объектам вижу два пути. Каррируем метод объекта и получаем…
1.… новую функцию;
2.… новый объект с тем же интерфейсом плюс новый метод.
Оба случая должны оперировать произвольным объектом с произвольными методами. При чем так, чтобы ни объект, ни методы не знали о том как с ними обращаются.
В Вашем же подходе, чтобы каррировать метод объекта нужно вмешаться в иерархию наследования и изменить конструктор.
Поясните, пожалуйста, в чём здесь заключаются каламбуры?
2. extract безопаснее Вашего первого способа, там можно указать некоторые настройки. Что касается объектов. Тут нельзя будет использовать extract. Опять же можно всяким мусором заполнить объект. И если все объекты для конфигурирования будут показывать свои свойства всем, то, скажем так, это открывает слишком много секретов, которые должны быть скрыты. Не будет интерфейсов, потому что все свойства будут открыты. Передал один объект он заполнился, передал другой объект, он точно так же заполнился и даже не поперхнулся.
3. Заполнение переменных и объектов будет зависеть не от программы, а от внешних факторов. Т.е. не так как хочет программист, а как повезёт. Передал/не передал, строка/массив. Конечно, можно фильтровать, но объектам не нужны одинаково отфильтрованные данные. Кому-то нужен массив, кому-то числовая строка, а кому-то любая строка подойдёт. Как место_где_распихиываются_данные_по_объектам узнает какому объекту что и в каком формате надо?
1. Можно использовать foreach вместо for
2. А ещё лучше использовать extract
3. А ещё лучше не использовать такой подход в принципе. Можно переписать существующие переменные (свойства). Можно не найти концов при отладке, когда переменные таким неявным способом инициализируются.
PS. register_globals в своё время пилили-пилили и выпилили, а тут прямо-таки «назад в будущее», вернее сказать «вперёд в прошлое».
Я вижу как идёт спор. Вы противопоставляете разработку на чистом языке разработке на фреймворке, показываете недостатки языка и достоинства фреймворка, сравниваете некоторых разработчиков на одном с некоторыми разработчиками на другом.
От кого скрываем?
От пользователя класса? — нет, в общем случае это невозможно. Пользователь может просто заглянуть в класс и всё посмотреть. А от себя так, вообще, не скроешь.
От кода, который использует класс? — нет, языки часто позволяют обходить эти защитные штуки, допустим, отражениями (рефлексиями). Поэтому нет технической возможности не допускать неправильные использования класса.
Получается, что у пользователя есть возможность обращаться к внутренностям реализации через то или иной манёвр, но это он не делает в повседневном коде. Почему? Потому язык говорит, что так не хорошо делать. И он с ним, как бы, договорился. Если язык не позволяет скрывать что-то в полной мере, то программисты договариваются между собой что скрыто, а что нет.
Ещё можно вспомнить для чего было придумано ООП. Чтобы было проще программировать. Как инкапсуляция позволяет упростить написание кода?
1. Упрощается абстракция. В момент использования класса мы можем «забыть» все его внутренности, и использовать только то, что открыто. Т.е. не надо помнить как какой класс и как именно реализован и что он будет использовать.
2. Локализовать будущие изменения. Изменения того или иного куска кода будет проще, если мы будем знать кто им пользуется. Инкапсуляция позволяет сократить таких пользователей путём расстановки ограничений.
В Вашем же случае либо придётся написать дополнительное условие
, либо при каждом запросе обращаться к базе.
en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29
Кстати, как Вы думаете, для чего нужна инкапсуляция?
Эм… методы для этого и нужны, чтобы работать с внутренним состоянием объекта. А как они это делают не наша забота.