Здравствуйте, samius, Вы писали:
S>>>А ты заглядывал в классическую реализацию, хотя бы в GoF?
SW>>А ты перестал опохмеляться по утрам ? S>Ниужели мой вопрос поставил тебя в то положение, в которое ты хочешь меня поставить своим ответом? Если да, то разбирайся в вопросах до того как делать многозначительные заявления. Если нет — то выразить свое нежелание общаться на эту тему можно было более дипломатично.
Здравствуйте, samius, Вы писали:
SW>>Назови несколько примеров, где можно разместить Extension методы. S>О, ну конечно! Extension методы ради Extension методов. Нужно было напилить Extension методов что бы мужественно решать проблемы по пропихиванию в них зависимостей в таких количествах.
Это считать ответом ?
SW>>С таким подходом всё становится контрактом И я даже не знаю, что в этом случае не будет контрактом. S>Так ты согласился?
Свести к абсурду можно любую идею и у тебя это хорошо вышло.
S>Именно так и рождаются толкования, когда хочется понять не то, что написано автором, а то что хочется.
У автора не истина в последней инстанции, а всего лишь мнение. С этого начинается понимание.
SW>>С твоей точки зрения здесь уже реализован IoC потому как ты рассматриваешь это исключительно как переход от процедурнго к ОО-подходу и здесь всё как у Фаулера " my car is special because it has wheels". S>Неверно. Здесь IoC не потому что ОО, а потому что зависимости приходят извне.
Назови примеры, когда зависимости в ОО приходят не извне
SW>>IoC же работает и в ОО-подходе и в функциональном и в любом другом. Если ты посмотришь внимательно, то быстро поймешь, что практически везде вызывающий код можно сделать вызываемым. S>IoC не делает вызывающий код вызываемым.
Это большое заблуждение.
S>Фаулер: S>
S>In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.
Отделение конфигурции от использования это инверсия, т.к. вызывающий становится вызываемым.
SW>>Ты прекратил опохмеляться ? S>Вижу тебе так понравилась чья-то выходка, что ты ее решил повторить дважды
Многим людям не нравятся их собственные методы. Ты один из таких.
SW>>Надеюсь, этих попыток было больше нуля. S>Ты делаешь все что бы свести их к отрицательному числу.
Если это правда, то число этих попыток никогда не было больше нуля.
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>>>Назови несколько примеров, где можно разместить Extension методы. S>>О, ну конечно! Extension методы ради Extension методов. Нужно было напилить Extension методов что бы мужественно решать проблемы по пропихиванию в них зависимостей в таких количествах.
SW>Это считать ответом ?
Считай это частью диагноза
SW>>>С таким подходом всё становится контрактом И я даже не знаю, что в этом случае не будет контрактом. S>>Так ты согласился?
SW>Свести к абсурду можно любую идею и у тебя это хорошо вышло.
S>>Именно так и рождаются толкования, когда хочется понять не то, что написано автором, а то что хочется.
SW>У автора не истина в последней инстанции, а всего лишь мнение. С этого начинается понимание.
Понимание кончается там, где начинаешь считать абсурдом и мнением то что написал не ты.
SW>>>С твоей точки зрения здесь уже реализован IoC потому как ты рассматриваешь это исключительно как переход от процедурнго к ОО-подходу и здесь всё как у Фаулера " my car is special because it has wheels". S>>Неверно. Здесь IoC не потому что ОО, а потому что зависимости приходят извне.
SW>Назови примеры, когда зависимости в ОО приходят не извне
public Component()
{
_dep1 = new Dep1();
}
SW>>>IoC же работает и в ОО-подходе и в функциональном и в любом другом. Если ты посмотришь внимательно, то быстро поймешь, что практически везде вызывающий код можно сделать вызываемым. S>>IoC не делает вызывающий код вызываемым.
SW>Это большое заблуждение.
Может опровергнешь мое утверждение примером, разнообразия ради?
S>>Фаулер: S>>
S>>In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.
SW>Отделение конфигурции от использования это инверсия, т.к. вызывающий становится вызываемым.
SW>>>Ты прекратил опохмеляться ? S>>Вижу тебе так понравилась чья-то выходка, что ты ее решил повторить дважды
SW>Многим людям не нравятся их собственные методы. Ты один из таких.
Мне не нравятся твои методы.
SW>>>Надеюсь, этих попыток было больше нуля. S>>Ты делаешь все что бы свести их к отрицательному числу.
SW>Если это правда, то число этих попыток никогда не было больше нуля.
В милое логическое противоречие ты себя поставил этим утверждением.
Здравствуйте, samius, Вы писали:
SW>>Это считать ответом ? S>Считай это частью диагноза
Ты долго с собой боролся
SW>>У автора не истина в последней инстанции, а всего лишь мнение. С этого начинается понимание. S>Понимание кончается там, где начинаешь считать абсурдом и мнением то что написал не ты.
Здесь все в порядке — абсурдным я считаю только часть написаного тобой в этом топике.
SW>>>>IoC же работает и в ОО-подходе и в функциональном и в любом другом. Если ты посмотришь внимательно, то быстро поймешь, что практически везде вызывающий код можно сделать вызываемым. S>>>IoC не делает вызывающий код вызываемым.
SW>>Это большое заблуждение. S>Может опровергнешь мое утверждение примером, разнообразия ради?
Опровергнуть можно только проверяемые, фальсифицируемые утверждения, к которым твоё "IoC не делает вызывающий код вызываемым" никак не относится.
SW>>Многим людям не нравятся их собственные методы. Ты один из таких. S>Мне не нравятся твои методы.
Еще бы, я ведь просто отфутболиваю тебе твоё же.
SW>>Если это правда, то число этих попыток никогда не было больше нуля. S>В милое логическое противоречие ты себя поставил этим утверждением.
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>>>У автора не истина в последней инстанции, а всего лишь мнение. С этого начинается понимание. S>>Понимание кончается там, где начинаешь считать абсурдом и мнением то что написал не ты.
SW>Здесь все в порядке — абсурдным я считаю только часть написаного тобой в этом топике.
Оставлю это твоей проблемой.
SW>>>>>IoC же работает и в ОО-подходе и в функциональном и в любом другом. Если ты посмотришь внимательно, то быстро поймешь, что практически везде вызывающий код можно сделать вызываемым. S>>>>IoC не делает вызывающий код вызываемым.
SW>>>Это большое заблуждение. S>>Может опровергнешь мое утверждение примером, разнообразия ради?
SW>Опровергнуть можно только проверяемые, фальсифицируемые утверждения, к которым твоё "IoC не делает вызывающий код вызываемым" никак не относится.
Вот еще одна логическая лужа, в которую ты сел. Ты понял о чем речь, классифицировал это утвреждение как заблуждение, но не смог его фальсифицировать. Это можно было бы сделать тривиально, если бы ты был прав. Достаточно было бы привести IoC, который вызывающий код делает вызываемым.
Судя по твоим словам, ты фальсифицировал нефальсифицируемое.
SW>>>Многим людям не нравятся их собственные методы. Ты один из таких. S>>Мне не нравятся твои методы.
SW>Еще бы, я ведь просто отфутболиваю тебе твоё же.
Давай разберемся
SW>>Я рассматриваю State, а не транзишн. В State в классической реализации выходной сигнал зависит только от состояния.
S>А ты заглядывал в классическую реализацию, хотя бы в GoF?
А ты перестал опохмеляться по утрам ?
Я спросил тебя, видел ли ты классическую реализацию State. Имею поводы, т.к. во-первых, ты неоднократно ссылался на "современную" литературу и отвергал классику в аспекте IoC. Во-вторых, реализация State в GoF представляет собой типичный автомат Мили, т.к. выходная функция зависит от входного сигнала в том числе. Вот и встал вопрос, какую именно реализацию State ты считаешь классической, и видел ли ты то что в GoF?
Однако, по существу вопроса у тебя ответа не нашлось, что видимо и послужило поводом к демонстрации манер.
SW>>>Если это правда, то число этих попыток никогда не было больше нуля. S>>В милое логическое противоречие ты себя поставил этим утверждением.
SW>Здесь нет противоречия
Здравствуйте, samius, Вы писали:
SW>>Опровергнуть можно только проверяемые, фальсифицируемые утверждения, к которым твоё "IoC не делает вызывающий код вызываемым" никак не относится. S>Вот еще одна логическая лужа, в которую ты сел. Ты понял о чем речь, классифицировал это утвреждение как заблуждение, но не смог его фальсифицировать.
Я классифицировал это утверждение как нефальсифицируемое.
>Это можно было бы сделать тривиально, если бы ты был прав. Достаточно было бы привести IoC, который вызывающий код делает вызываемым.
Этого недостаточно.
S>Судя по твоим словам, ты фальсифицировал нефальсифицируемое.
Нечего фальсифицировать
S>>А ты заглядывал в классическую реализацию, хотя бы в GoF? S>Я спросил тебя, видел ли ты классическую реализацию State. Имею поводы, т.к. во-первых, ты неоднократно ссылался на "современную" литературу и отвергал классику в аспекте IoC. Во-вторых, реализация State в GoF представляет собой типичный автомат Мили, т.к. выходная функция зависит от входного сигнала в том числе.
Не зависит от входного сигнала, а исключительно от состояния.
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>Я классифицировал это утверждение как нефальсифицируемое.
SW>Нечего фальсифицировать
И тем не менее, это же не я придумал:
SW>Это большое заблуждение.
Если утверждаешь что это заблуждение — опровергай. Если утверждаешь что оно нефальсифицируемое — не называй это заблуждением. Палишься на элементарной логике.
S>>Я спросил тебя, видел ли ты классическую реализацию State. Имею поводы, т.к. во-первых, ты неоднократно ссылался на "современную" литературу и отвергал классику в аспекте IoC. Во-вторых, реализация State в GoF представляет собой типичный автомат Мили, т.к. выходная функция зависит от входного сигнала в том числе.
SW>Не зависит от входного сигнала, а исключительно от состояния.
Следовательно, твоя интерпретация примера GoF передает физическому соединению одинаковую команду на сигналы Close, Open и т.п., принятые в некотором из состояний.
Здравствуйте, samius, Вы писали:
SW>>Нечего фальсифицировать S>И тем не менее, это же не я придумал: S>
SW>>Это большое заблуждение.
S>Если утверждаешь что это заблуждение — опровергай. Если утверждаешь что оно нефальсифицируемое — не называй это заблуждением. Палишься на элементарной логике.
Нефальсифицируемое -> заблуждение. Это и есть элементарная логика. Ты пойми, никто не опровергает теорию "зелёных невидимых гномиков"
SW>>Не зависит от входного сигнала, а исключительно от состояния. S>Следовательно, твоя интерпретация примера GoF передает физическому соединению одинаковую команду на сигналы Close, Open и т.п., принятые в некотором из состояний. S>
Ты попутал функцию и результат этой функции и меня это не удивляет.
Здравствуйте, Sharad-Waador, Вы писали:
V>>Смысл рассматривать один из внутренних блоков, который всегда приватный? Это интимные вопросы реализации, которые не видны в публичном доступе. Это относится к паттерну State, если мы всё еще о нем, а не о чем-то новом, которое ты не озвучил.
SW>Я рассматриваю State, а не транзишн. В State в классической реализации выходной сигнал зависит только от состояния.
Где это ты видел в паттерне "выходные сигналы"?
Хорошо смотрел? В "State в классической реализации" от состояния зависит поведение, но это же есть классическое определение автомата Мили.
Здравствуйте, vdimas, Вы писали:
V>Где это ты видел в паттерне "выходные сигналы"? V>Хорошо смотрел? В "State в классической реализации" от состояния зависит поведение, но это же есть классическое определение автомата Мили.
А в автомате мура поведение не зависит от состояния ?
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
S>>И тем не менее, это же не я придумал: S>>
SW>>>Это большое заблуждение.
S>>Если утверждаешь что это заблуждение — опровергай. Если утверждаешь что оно нефальсифицируемое — не называй это заблуждением. Палишься на элементарной логике.
SW>Нефальсифицируемое -> заблуждение. Это и есть элементарная логика. Ты пойми, никто не опровергает теорию "зелёных невидимых гномиков"
Логика железная Согласно ей, твоя классификация моего утверждения — тоже заблуждение.
SW>>>Не зависит от входного сигнала, а исключительно от состояния. S>>Следовательно, твоя интерпретация примера GoF передает физическому соединению одинаковую команду на сигналы Close, Open и т.п., принятые в некотором из состояний. S>>
SW>Ты попутал функцию и результат этой функции и меня это не удивляет.
Ну-ка, подробнее! У тебя функция не зависит от сигнала, а ее результат зависит? Или у тебя результат — это функция, полученная частичным применением? Теоретики автоматостроения просто прифигели бы от такого сведения Мили к Муру.
Здравствуйте, samius, Вы писали:
SW>>Нефальсифицируемое -> заблуждение. Это и есть элементарная логика. Ты пойми, никто не опровергает теорию "зелёных невидимых гномиков" S>Логика железная Согласно ей, твоя классификация моего утверждения — тоже заблуждение.
Ни в коем случае.
SW>>Ты попутал функцию и результат этой функции и меня это не удивляет. S>Ну-ка, подробнее! У тебя функция не зависит от сигнала, а ее результат зависит? Или у тебя результат — это функция, полученная частичным применением? Теоретики автоматостроения просто прифигели бы от такого сведения Мили к Муру.
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>>>Нефальсифицируемое -> заблуждение. Это и есть элементарная логика. Ты пойми, никто не опровергает теорию "зелёных невидимых гномиков" S>>Логика железная Согласно ей, твоя классификация моего утверждения — тоже заблуждение.
SW>Ни в коем случае.
Если так, то доказывай его.
S>>Ну-ка, подробнее! У тебя функция не зависит от сигнала, а ее результат зависит? Или у тебя результат — это функция, полученная частичным применением? Теоретики автоматостроения просто прифигели бы от такого сведения Мили к Муру.
SW>Смотри внимательно: SW>Close() { return ctx.Connection.Close(); } SW>Close() { throw new exception(); }
SW>Выходной сигнал — Close, он изменяется в зависимости от состояния.
Только речь о сигналах, а не о состояниях. Проспись.
Здравствуйте, samius, Вы писали:
SW>>Ни в коем случае. S>Если так, то доказывай его.
"IoC не делает вызывающий код вызываемым". Самый простой способ — IoC вообще ничего не может делать, потому что это принцип, а не живое существо Отсюда ты сам догадаешься, что же за высказывание ты родил.
S>>>Ну-ка, подробнее! У тебя функция не зависит от сигнала, а ее результат зависит? Или у тебя результат — это функция, полученная частичным применением? Теоретики автоматостроения просто прифигели бы от такого сведения Мили к Муру.
SW>>Смотри внимательно: SW>>Close() { return ctx.Connection.Close(); } SW>>Close() { throw new exception(); }
SW>>Выходной сигнал — Close, он изменяется в зависимости от состояния. S>Только речь о сигналах, а не о состояниях. Проспись.
"Выходной сигнал — Close..." И кому нужно проспаться ?
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>>>Ни в коем случае. S>>Если так, то доказывай его.
SW>"IoC не делает вызывающий код вызываемым". Самый простой способ — IoC вообще ничего не может делать, потому что это принцип, а не живое существо Отсюда ты сам догадаешься, что же за высказывание ты родил.
Подтверждением моего высказывания ты доказываешь верность предположения что это заблуждение?
S>>>>Ну-ка, подробнее! У тебя функция не зависит от сигнала, а ее результат зависит? Или у тебя результат — это функция, полученная частичным применением? Теоретики автоматостроения просто прифигели бы от такого сведения Мили к Муру.
SW>>>Выходной сигнал — Close, он изменяется в зависимости от состояния. S>>Только речь о сигналах, а не о состояниях. Проспись.
SW>"Выходной сигнал — Close..." И кому нужно проспаться ?
Тебе. Ты же утверждаешь, что выходной сигнал зависит только от состояния, следовательно не зависит от входного. По твоей логике реакцией на входной сигнал Open будет тоже Close.
Здравствуйте, samius, Вы писали:
SW>>"IoC не делает вызывающий код вызываемым". Самый простой способ — IoC вообще ничего не может делать, потому что это принцип, а не живое существо Отсюда ты сам догадаешься, что же за высказывание ты родил. S>Подтверждением моего высказывания ты доказываешь верность предположения что это заблуждение?
И где ты увидел подтверждение ? Покажи, может я чего пропустил.
SW>>>>Выходной сигнал — Close, он изменяется в зависимости от состояния. S>>>Только речь о сигналах, а не о состояниях. Проспись.
SW>>"Выходной сигнал — Close..." И кому нужно проспаться ? S>Тебе. Ты же утверждаешь, что выходной сигнал зависит только от состояния, следовательно не зависит от входного. По твоей логике реакцией на входной сигнал Open будет тоже Close.
Это твоя логика, а не моя и похоже, с тобой вообще не о чем говорить, т.к. про автоматы Мура ты только слышал. При получении сигнала Open реакцией будет смена состояния, а не выходной сигнал Close !!!
Кроме того, выходной сигнал это не один Close(или Open,Send), а конкретный набор Close,Open,Send и набор появляется не как попало, а в конкретном состоянии.
Разницу чувствуешь между своей и моей логикой ?
В двоичном автомате Close может быть двух уровней — 0 и 1. В нашем случае этих "уровней" может быть сколько угодно.
Последняя разница — в конкретной реализации State входные сигналы могут быть совмещены с выходными.
То есть,
в состоянии открыто
Open даёт исключение,
Close закрывает и переключает состояние на закрыто,
Send отсылает
в состоянии закрыто
Open открывает и переключает в состояние открыто,
Close дает исключение,
Send дает исключение
— классика Мили с учетом особенности State.
Всё, ликбез окончен и считай это твоим точным диагнозом.
Здравствуйте, Sharad-Waador, Вы писали:
SW>Здравствуйте, samius, Вы писали:
SW>>>"IoC не делает вызывающий код вызываемым". Самый простой способ — IoC вообще ничего не может делать, потому что это принцип, а не живое существо Отсюда ты сам догадаешься, что же за высказывание ты родил. S>>Подтверждением моего высказывания ты доказываешь верность предположения что это заблуждение?
SW>И где ты увидел подтверждение ? Покажи, может я чего пропустил.
Выделил. Вообще ничего не может — это более широкое утверждение чем то что "IoC не делает нечто".
SW>>>"Выходной сигнал — Close..." И кому нужно проспаться ? S>>Тебе. Ты же утверждаешь, что выходной сигнал зависит только от состояния, следовательно не зависит от входного. По твоей логике реакцией на входной сигнал Open будет тоже Close.
SW>Это твоя логика, а не моя и похоже, с тобой вообще не о чем говорить, т.к. про автоматы Мура ты только слышал. При получении сигнала Open реакцией будет смена состояния, а не выходной сигнал Close !!!
Ты же утверждал что реакция будет зависеть от состояния? Это ведь не я утверждал.
SW>Кроме того, выходной сигнал это не один Close(или Open,Send), а конкретный набор Close,Open,Send и набор появляется не как попало, а в конкретном состоянии.
Вижу что про автоматы ты только слышал.
SW>Разницу чувствуешь между своей и моей логикой ?
Прости, между моей логикой и чем? Я ошибался, считая что она у тебя есть.
SW>В двоичном автомате Close может быть двух уровней — 0 и 1. В нашем случае этих "уровней" может быть сколько угодно.
В вашем с кем случаем?
SW>Последняя разница — в конкретной реализации State входные сигналы могут быть совмещены с выходными. SW>То есть, SW>в состоянии открыто SW> Open даёт исключение, SW> Close закрывает и переключает состояние на закрыто, SW> Send отсылает SW>в состоянии закрыто SW> Open открывает и переключает в состояние открыто, SW> Close дает исключение, SW> Send дает исключение SW>- классика Мили с учетом особенности State.
Сравни это с этим твоим утверждением. http://www.rsdn.ru/forum/philosophy/4300593.1.aspx
SW>Всё, ликбез окончен и считай это твоим точным диагнозом.
Твой диагноз — раздвоение личности. Которая из них дает мне диагнозы — мне даже не интересно.
Здравствуйте, samius, Вы писали:
SW>>>>"IoC не делает вызывающий код вызываемым". Самый простой способ — IoC вообще ничего не может делать, потому что это принцип, а не живое существо Отсюда ты сам догадаешься, что же за высказывание ты родил. S>>>Подтверждением моего высказывания ты доказываешь верность предположения что это заблуждение?
SW>>И где ты увидел подтверждение ? Покажи, может я чего пропустил. S>Выделил. Вообще ничего не может — это более широкое утверждение чем то что "IoC не делает нечто".
Ты использовал пустое по смыслу сообщение как аргумент да еще хватило наглости заявлять что оно фальсифицируемо
SW>>Последняя разница — в конкретной реализации State входные сигналы могут быть совмещены с выходными. SW>>То есть, SW>>в состоянии открыто SW>> Open даёт исключение, SW>> Close закрывает и переключает состояние на закрыто, SW>> Send отсылает SW>>в состоянии закрыто SW>> Open открывает и переключает в состояние открыто, SW>> Close дает исключение, SW>> Send дает исключение SW>>- классика Мили с учетом особенности State. S>Сравни это с этим твоим утверждением. S>http://www.rsdn.ru/forum/philosophy/4300593.1.aspx
я ошибся "классика Мура" а не Мили, т.к. речь про Муа. По ссылке :"В State в классической реализации выходной сигнал зависит только от состояния."
С этим сообщением все в порядке — каждый из выходных сигналов зависит только от состояния и ничего больше. Если состояние открыто, то сигнал Close всегда будет функцией закрытия, сигнал Open всегда будет функцией которая бросает исключение и тд. И ни от чего более эти сигналы не зависят — ни от чего, кроме как от состояния.
P.S. Похоже ты и вправду не понимаешь, что такое автомат Мура. Если тебе понятно написаное здесь, считай что ты понял автомат Мура. Это снова диагноз.
И я даже не знаю, что в этом случае не будет контрактом.
