Въпросче?

Аз не виждам къде се създава втори Config? (което, изглежда, беше проблемът в предишния пост - че се създават 2). В постнатия код създаваш само един.

Тук обаче казваш „След кеша независимо колко пъти го викам, бройката не се увеличава“. Да разбирам ли, че Config си се създава само веднъж (както си трябва), или нещо друго имаш предвид?
 
Знам че изглежда така, но резултатите от тестовете с брояча в конструктора са други. За да обясня по-ясно малко ще се отклоня от Config за момент. Да кажем създавам си един клас Test, и го инжектирам в App три пъти. Без кеша брояча показва 3, със кеша 1, което си е както трябва. По същия начин инжектирам Config в App три пъти. Без кеша брояча показва 5, със кеша 3, което пак е правилната бройка защото трябва да се вземе предвид че контейнера създава копието което се кешира. Двете излишни са тези които подавам на Loader и Container.
 
трябва да се вземе предвид че контейнера създава копието което се кешира

На този ред:
$container = new application\Container($config);

Контейнерът не прави копие на Config - нали получава вече създадена инстанция?
 
anonimen каза:
трябва да се вземе предвид че контейнера създава копието което се кешира

На този ред:
$container = new application\Container($config);

Контейнерът не прави копие на Config - нали получава вече създадена инстанция?

Напротив прави. Аз го получавам един път в конструктора и го ползвам в логиката на самия контейнер. Обаче целта на контейнера е да създаде нов обект накрая, както и ако този обект има зависимости да създаде и тях и т.н.

Код:
return $reflector->newInstanceArgs($dependencies);

И когато го инжектирам отново например в App той му създава ново копие.
 
Нали като получиш конфиг обект в конструктора:

PHP:
new application\Container($config);
го кешираш (както с останалите сингълтони), и от там нататък си ползваш все тази инстанция?

целта на контейнера е да създаде нов обект накрая
А тук какво имаш предвид? Накрая на конструктора ли?
 
Имам чувството че говорим на различен език :D .

Виж последователността и може би ще разбереш.

Config->Loader->Container->__constructor(Config)->function make()->App->__constructor(Config)

Преди function make() няма кеш, в тази функция става всичко, което значи че няма как да кеширам при положение че конструктора се изпълнява първи. След тази функция, в конструкторите на другите класове например App, вече всичко е кеширано.
 
teroristd каза:
Имам чувството че говорим на различен език :D .
Защото говоря извън твоя контекст и нещата, които ми се струват очевидни, явно при теб няма как да се случат „просто така“.

Виж последователността и може би ще разбереш.

Config->Loader->Container->__constructor(Config)->function make()->App->__constructor(Config)

Преди function make() няма кеш, в тази функция става всичко, което значи че няма как да кеширам при положение че конструктора се изпълнява първи. След тази функция, в конструкторите на другите класове например App, вече всичко е кеширано.
Под „кеш“ разбирам масив (примерно), който стои в Container и държи всякакви обекти, които иначе биха били инстанции на singletonи.

Ето как си представям ситуацията аз:
При създаване на Container (c new), ти подаваш вече инстанцииран Config. (както правиш в index)
В конструктора на Container записваш подадения Config в кеша.
Всички по-нататъшни requestи към Container за Config ще върнат тази кеширана инстанция, и няма откъде да дойде второ копие на Config, защото Container вече ще си държи инстанция.

Това не би трябвало да има нищо общо с това какви Loaderи и Appове ползваш, защото се отнася единствено до Container.
 
Благодаря @anonimen, в крайна сметка с малко смяна на логиката в Container се получи желаният резултат. Мисля че вече съм в крачка със SOLID или поне съм доста близо :) .
 
teroristd каза:
Благодаря @anonimen, в крайна сметка с малко смяна на логиката в Container се получи желаният резултат. Мисля че вече съм в крачка със SOLID или поне съм доста близо :) .

Шерни си някъде кода да гледаме :))
 
teroristd каза:
Какво искаш да видиш, контейнера ли :)?
Системата Loader/Container/App, и кое как и къде си решил да разпределиш. Контейнерът е горе-долу ясен - контейнери по интернет бол; но неща като App аз лично само съм използвал, и то неявно, в symfony, без да съм особено сигурен кое какво точно прави.
Ще ми е интересно да видя „едноличен човешки“ подход към тази система.
 
Кажете къде да ги шервам? Ако ги пусна тук не знам дали ще стане ясна структурата, пък и ще стане доста кода. Колкото за App, в момента още не е готов. Не знам дали има изобщо нещо общо с AppKernel на symfony, но при мен е така да се каже, мястото където стартира цялото приложение. App получава класовете за сесиите, error handling-а, front controller-a и т.н. вижда каква е конфигурацията и стартира приложението според настройките.
 
Лошо няма но освен че трябва да се регистрирам друго не знам за github. Ако някой ми разясни как се ползва ще се пробвам :) .
 
anonimen каза:
teroristd каза:
Ето линк към GitHub, надявам се да съм го направил правилно :).
https://github.com/teroristd/Solid
При качването са ти избягали разширенията, които hintват github за syntax highlighting.

Не знам за какво ми говориш. Аз давам create new file, пействам кода и натискам commit new file. Какви са тези разширения и какво трябва да направя за да не бягат :D ?
 
teroristd каза:
anonimen каза:
teroristd каза:
Ето линк към GitHub, надявам се да съм го направил правилно :).
https://github.com/teroristd/Solid
При качването са ти избягали разширенията, които hintват github за syntax highlighting.

Не знам за какво ми говориш. Аз давам create new file, пействам кода и натискам commit new file. Какви са тези разширения и какво трябва да направя за да не бягат :D ?

Какво IDE ползваш за PHP? Очевидно гит ти е тъмна индия :)

btw: Loader класа мисля, че работи само под windows.

Погледни и това: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md
 

Горе