А используете ли вы вышеозначенную методологию в разработке (неважно на каком языке, устроит и JS). Можно привести пример каких-нибудь реальных задач, решенных с ее помощью? Как потом поддерживается код/какие особенности при написании юнит-тестов/да и какие возникают проблемы в целом?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А используете ли вы вышеозначенную методологию в разработке (неважно на каком языке, устроит и JS). Можно привести пример каких-нибудь реальных задач, решенных с ее помощью? Как потом поддерживается код/какие особенности при написании юнит-тестов/да и какие возникают проблемы в целом?
Только в прототипах на C#
Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
То есть фактически вся мощь не задействована. Так же как и в в классическом ООП наследование не есть ООП, а только средство. А ООП это способ построения модели задачи
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
AS>Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Ведмедь, Вы писали:
В>Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
Ну как сказать... Не раз видел попытки сымитировать на JS class based OOP, т.е. когда люди пытались тем или иным способом ввести в язык явное описание контрактов. Видел, как его использовали как функциональный язык — причем весьма часто. А вот более родной, казалось бы, механизм несколько уступает в популярности.
Здравствуйте, Воронков Василий, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
Здравствуйте, Lloyd, Вы писали:
L>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
Здравствуйте, Воронков Василий, Вы писали:
L>>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
ВВ>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Ведмедь, Вы писали:
В>>Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
ВВ>Ну как сказать... Не раз видел попытки сымитировать на JS class based OOP, т.е. когда люди пытались тем или иным способом ввести в язык явное описание контрактов. Видел, как его использовали как функциональный язык — причем весьма часто. А вот более родной, казалось бы, механизм несколько уступает в популярности.
JS и есть функциональный язык, функции в нём first class.
Плюс корни у него схемовские.
Здравствуйте, Lloyd, Вы писали:
L>>>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
ВВ>>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
L>Зачем? Юзкейс можешь привести?
Зачем что? Сам механизм delegation-a? Ну одно из самых очевидных преимуществ этой парадигмы в меньших требованиях к памяти — у нас фактически происходит даже не клонирования, а передача новому объекту всех слотов исходного, а новые слота создаются только при явной записи значений в них.
Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи.
В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках.
Здравствуйте, Курилка, Вы писали:
К>JS и есть функциональный язык, функции в нём first class.
Предлагаю не начинать спор о том, что делает язык функциональным
В JS — по кр. мере до 1.8 — кроме функций как первоклассных объектов ничего больше и нет. Плюс стоимость вызова функций весьма высока, если императивный алгоритм переписать в функциональном стиле, то он будет раз в 5 медленнее. Все же очень многое в языка располагает к созданию побочных эффектов, причем зачастую просто чудовищных, и нет никаких средств для борьбы с "нечистотой". На мой взгляд в функциональном языке такие средства быть должны.
А если бы в нем не было функций как первоклассных объектов, то вообще в функциональном стиле писать было бы нельзя.
К>Плюс корни у него схемовские.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Курилка, Вы писали:
К>>Плюс корни у него схемовские.
ВВ>Разве? Не вижу связи. Откуда такое мнение?
Например, и ещё отсюда (надеюсь достаточно говорящий адрес?):
ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme. The programming style is a mixture of object-based and functional programming: The
primary abstraction mechanisms in ES3 are lexically scoped higher-order functions and mutable objects
whose prototype objects contain methods that are accessible through a delegation mechanism.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Курилка, Вы писали:
К>>Например, и ещё отсюда (надеюсь достаточно говорящий адрес?):
ВВ>Адрес говорящий, но недоумение осталось. Можете привести что-либо такое, что явно сближает третью редакцию именно со Схемой?
Не понимаю почему именно 3-ю и "сближает"?
По-моему лямбд и замыканий уж достаточно.
А вообще утверждается, что Эйх должен был выл встроить Схему в браузер (ед. упоминание, что сходу нашёл — http://wapedia.mobi/ru/JavaScript ), только синтаксис побоялись давать широкой публике, ну и (есть подозрение, что) Сан удалось в том числе близостью к Java взять в союзники против МС.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Можно привести пример каких-нибудь реальных задач, решенных с ее помощью?
Достоточно часто.
Например некий widget у которого есть два и больше режима работы.
Скажем есть начальное состояние "загрузка" и "нормальная работа":
class LoadingState: Behavior
{
...
function onMouse(evt) { ... еще не работа но уже надо что-то делать ... ; }
function whenLoaded() { this.prototype = WorkingState; } // changing class of the object
}
class ReadyState: Behavior
{
...
function onMouse(evt) { ... нормальная обработка ... ; }
}
Если "загрузка" это потенциально длительный процесс то чтобы не городить кучу конструкций типа
if(loading) ... else ...;
используем динамическое переключение класса. Кода меньше получается и работает быстрее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
L>>Зачем? Юзкейс можешь привести?
ВВ>Зачем что? Сам механизм delegation-a? Ну одно из самых очевидных преимуществ этой парадигмы в меньших требованиях к памяти — у нас фактически происходит даже не клонирования, а передача новому объекту всех слотов исходного, а новые слота создаются только при явной записи значений в них.
Гм. А при записи полей прототипы разве работают? Я был уврен, что нет. Надо бы проверить
ВВ>Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи. ВВ>В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках.
Ну почему сразу невозможно? Делегирование методов на синглтон + подмена стратегии синглтона.
Здравствуйте, Lloyd, Вы писали:
L>Гм. А при записи полей прототипы разве работают? Я был уврен, что нет. Надо бы проверить
В смысле "прототипы при записи полей"? Я описал механизм по которому работает P-OOP через delegation. Если ты создал новый объект по некому прототипу, то память под "поля" выделяться не будет до тех пор, пока ты явно не запишешь в них значения (этой создаст новый слот). Если ты просто читаешь — то будешь брат данные из слота прототипа.
ВВ>>Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи. ВВ>>В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках. L>Ну почему сразу невозможно? Делегирование методов на синглтон + подмена стратегии синглтона.
В том-то и дело, что через синглтон, т.е. некий глобальный инстанс. Почувствуй разницу, как говорится.
Не вижу связи. Откуда такое мнение?
