Вообще как я писал выше замыкания нужны для создания анонимных функции, странно что вы этого не знаете. Вся статья не о замыканиях, а о анонимных функциях!
Здесь как бы идёт речь о вложенных многоуровневых массивах с применением метода перегрузки объекта. Решения могут быть разными, например я бы расцеловал если бы вы написали как сделать следующий код выполняемым:
$a = new Parameters;
$a->b->c->d = 'variables';
Есть варианты? Тока две строчки, неважно как и что вы опишите в классе, не считается только хард-код как у автора;
Совершенно верно, во всяком случае сделать это так гибко как на Python или Ruby не получится! Единственный простой способ сделать многоуровневые вложенные контейнеры данных это определять их самом, методы перегрузки не помогут!
class ParameterHolder
{
private
$parameters = array();
public function __set($name, $value)
{
$this->parameters[$name] = $value;
}
public function & __get($name)
{
if (array_key_exists($name, $this->parameters))
{
$value = & $this->parameters[$name];
}
return $value;
}
}
// Применение
$parameters = new ParameterHolder();
$parameters->a1 = new ParameterHolder();
$parameters->a2 = new ParameterHolder();
$parameters->a2->b2 = new ParameterHolder();
Любой прокси код который обеспечивает доступ к данным ЧЕРЕЗ себя — декоратор
то есть любой геттер это декоратор? Пмойму вы пишите бред!
C тез пор как этот хард код используется внутри или при создании\описании внутрених данных, но не при доступе к нему
Вообще-то это и называется хард-код! Ведь если каждый раз когда придётся пере использовать этот код надо будет вносить изменение в класс: сорри это не вяжется с принципами ООП
Вы МОЖЕТЕ переопредилить get\set любого значения на выполнение любых действий.
Вплоть до того что при запросе some( в данном случае ) его внутрений массив будет подгружен. Это можно например расширить до развертки внешний ключей в моделе ORM.
Автор учи мат часть: Closure (computer science)!
ты видишь?
$a = new Parameters;
$a->b->c->d = 'variables';
Есть варианты? Тока две строчки, неважно как и что вы опишите в классе, не считается только хард-код как у автора;
то есть любой геттер это декоратор? Пмойму вы пишите бред!
C тез пор как этот хард код используется внутри или при создании\описании внутрених данных, но не при доступе к нему
Вообще-то это и называется хард-код! Ведь если каждый раз когда придётся пере использовать этот код надо будет вносить изменение в класс: сорри это не вяжется с принципами ООП
Вы МОЖЕТЕ переопредилить get\set любого значения на выполнение любых действий.
Вплоть до того что при запросе some( в данном случае ) его внутрений массив будет подгружен. Это можно например расширить до развертки внешний ключей в моделе ORM.
Что ты куришь?
2) С каких пор хард код называется контролем над записью данных?
я бы ещё понял если он инициализировал это в конструкторе:
3) Что значит навесить сколько угодно property? Разве есть какой то лимит?
В общем какая то непонятная реализация контейнера данных, причём непонятно зачем используются методы перегрузки, неужели без них не обойтись?