Здравствуйте, Курилка, Вы писали:

К>По факту получается, что паттерны — это слишком размазанное понятие,

Не размазанное, просто довольно широкое. Утаптывать его в рамки GoF не стоит. Главное, что я хотел заметить, в другом — если мы то, что я сказал, применим к статье в корне топика, то статья, по сути, привратиться в набор банальностей.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Курилка, Вы писали:

К>>По факту получается, что паттерны — это слишком размазанное понятие,

AVK>Не размазанное, просто довольно широкое. Утаптывать его в рамки GoF не стоит. Главное, что я хотел заметить, в другом — если мы то, что я сказал, применим к статье в корне топика, то статья, по сути, привратиться в набор банальностей.

А можно посмотреть это на с другой точки зрения: простые вещи типа визиторов и т.п. приравнивают к архитектурным паттернам и вместо того, чтобы реализовать просто удобный механизм, разводят религию аля "паттерны — это наше видение мира и надо всё описать паттернами". Т.е. как всегда крайности вещь вредная и надо находить золотую середину

Здравствуйте, gandalfgrey, Вы писали:

G>Здравствуйте, VladD2, Вы писали:

VD>>Своим частным мнением? Создай голосование, увидишь чего оно стоит.
G>Мы все еще говорим про надобность / необходимость IDE ?

Я бы даже сказал про обязательность качественной поддержки мощьной IDE для того чтобы большинство программистов решилось использовать язык.

G>А как создать голосование ?

Сами голосования тут: http://rsdn.ru/poll/polllist.aspx

За списком голосований есть пункт добавить голосование.
Только добавляя голосование имеет смысл оставить возможность добавления своего варианта, так как почти наверняка многие захотят высказать особое мнение.

Здравствуйте, Sinclair, Вы писали:

S>Влад, это потребует написания класса на каждый чих. Зачем?

Хороший такой чих. МС аж его захардкодил в язык и рантайм.
Меж тем создать такой класс нужно ровно один раз.

S>В качестве упражнения: попробуй реализовать аналогичную евентам функциональность в библиотеке на C# 2.0.

Синклер, ты меня извини, но ты меня с кем-то спутал. Я упражняюсь в программировании каждый день и ни в упражнениях, ни в учетелях не нуждаюсь. Более того считаю подобные предложения не корректно по отношению к другим программистам.

Что касается релизации на C# 2.0, то это действительно сложно так как язык не обладает базовыми элеми необходимыми для реализации этой возможности. А вот на Nemerle я тебе это реализую без особых проблем. Собственно об этом тебе и говорю.

VD>>Ключевое слово event в C# банально вводит свойство доступное только для чтения обеспечивая доступ к нему только по операторам + и -. В общем, бессмысленный хардкодинг.
S>Влад, в твоем возрасте пора бы уже привыкнуть к тому, что "Влад не видит смысла" != "бессмысленный".

Синклер, ты меня извини, но твой менторский тон мне не нравится. Или убери эту маску гуру, или давай завершим разговор. Я в своем возрасте, который замечу несколько больше твоего, прекрасно и сам знаю значения слов и умею соотносить множества.

Я выражаю свою точку зрения и не скрываю этого. Если ты не согласен с ней, то говори что-то по сущетсву, а не занимайся дешевыми переходами на личность оппнента.

S> Ключевое слово event, кстати, никакого свойства не вводит. Оно вводит два спецметода похожим на свойство образом. Кроме того, оно иногда автоматически вводит поле подходящего типа.

Это мелкие детали. По сути это тоже свойство вид сбоку. Тебе уже скзали, что небыло бы никакой разницы если бы вместо этих спец-методов был бы некий интерфейс с думя методами.

VD>>Да и кому такая инкапсуляция нужна. Это что инкапсуляция ради инкапсуляции?
S>Как бы всем.

Говори за себя. Я к этим всем не отношусь. Мня вообще в последнее время догмы парадигм все меньше колышат. Меня колышит только поростота и элегантность решения. Фича ради фичи — это религия.

S> Влад, евенты встречаются в дотнете сплошь и рядом.

Ага. Причем чаще всего по недаразумению и из-за отсуствия более удобных средств. Вот появится в C# 3.0 полноценная лямбда и сам увидишь, как потребность в ивентах резо уменшится.

Ну, и без этой инкапсуляции они вряд ли стали бы хуже. Если это такой способ борьбы с null, то он какой-то непоследовательный. Ведь от того что мы можем присвоить null в ссылочные свойства или поля оные хуже для нас не становятся. Просто другая семантика.

S> Инкапсуляция, очевидно, нужна для устойчивости кода к мелким ошибкам, непроверяемым компилятором.

Инкапсуляция — это инструмент достижения цели. И не всегда нужна эта цель. Например, вырожденные свойства никаой инкапсуляцией не являются. Это чистый синтаксический оверхэд. Так же многие типы данных используемые (особенно струтуры) не требуют инкапсуляции. Ее прикручиввают исключительно из-за соблюдения догматов.

S>>> В дотнете все грабли именно с тем, что для свойства есть риск сделать = вместо +=.
VD>>Для этого достаточно сделать свойство доступное только для чтения или такое же поле. В общем, это уже притягивание за уши никому не нужной фигни.
S>А общем, это уже просто нежелание напрячь мозг на 10 секунд чтобы понять очевидные вещи.

Я бы назвал это некооректным высказыванием. Что-то ты стал ими злоупотреблять в последнее время.

Представь, что имеется мнение отличное от твоего и представь, что твое мнение не является истиной в последней инстанции. Причем люди могут банально иметь более широкий опыт и тем самым мыслить чуть шире. Ты же не имея этого опыта смотря со своей колокольни видишь "их узость мышления" и считашь, что они "не хотят напрячь мог на 10 секунд". Выглядишь при этом ты довольно э... скажем так не с лучшей стороны. И даже если это не так и ты прав, то все равно хотя бы на всякий случай не стоит распростроняться об узости чужого пышления. Это как минимум не красит тебя лично.

VD>>Да и в Дельфи никогда проблем не видел.
S>Ну конечно не видел. Евенты в дельфи были одиночными, поэтому ситуация случайного переписывания обработчика вместо добавления в список не могла возникнуть.

Хм. Я мог присвоить им nil. Ты тут говорил, что это так плохо. А вот на практике оказывется что очень даже приемлемо.

S>Зато в тех местах, где была нужна множественная подписка, в VCL была написана просто тонна кода.

Я согласен, что список событий иногда удобнее. Но его нет проблем создать без хардкода.

В общем, ивенты — это хороший сахар для ООЯ, но не было никакой необходимости хардкодить его в рантайм дотнета. А в языке можно было добавить более универсальные средства на базе которых само событие получалось бы неотличимым от встроенного.

S> Поверь мне на слово, Влад, Хейльсберг гораздо лучше, чем ты, знает достоинства и недостатки Delphi.

Извини, но верить тебе у меня желания нет. Хейльсберг наделал ошибок в Дельфи и наделал их в C#. Отрадно видеть что ошибок в последнем меньше, но таки они есть и как раз мне, как постороннему наблюдателю использующему этот язык и знакомому с другими языками лучше выдны его ошибки. Ведь свои ошибки всегда видны хуже чем чужие.

S>Совершенно верно. Поддержка event в шарпе — это хорошо. Необходимость переделки компилятора для этого — плохо. Я уверен, что nemerle позволяет реализовывать такие вещи без обращения к разработчикам компилятора. Что позволяет надеяться на его повальное внедрение.

К сожалению, насколько я помню, ивенты захардкодили в рантайме дотнета. Они описываются в метаданных и т.п. Да и делегаты это явно надуманная сущьность. Они слишком конкретны. Весьма странно, что разные методы можно привести к одному делегату, но два одинаковых делегата не совместимы между собой. Это создает некторые проблемы. Меж тем есть боле естественное и более общее решение — фукнциональные типы. Как показала практика их без проблем можно создать на базе обыкровенных классов. При этом они получаются более понятными, логичными и даже работают быстрее. Да и не нужно делать отдельных оптимизаций, ведь можно просто оптимизировать работу с классами тем самым опримизируя и функциональные типы.

В общем, я тоже согласен что включение подобных средств в язык полезно, но не согласен ни со средствами вклюения, ни с дийаном конкретных реализаций. Чем меньше хардкода, тем лучше.

Здравствуйте, kan, Вы писали:

>> kan>А это точно всё?
>> Ага. Для событий все. Причем не нужно даже ядрёной енергии макросов.
>> Просто более грамотный дизайн языка.
kan>"640кб оперативной памяти должно быть достаточно для каждого".

Так. Кто оставил палату номер 6 открытой?

kan>Реализованный паттерн Посетитель это уже не паттерн, а конкретный алгоритм.

Алгоритм легко реализуется функцией. Реализуй Посетителя функцией и поглядим. Здесь идет речь об алгоритме реализации паттерна. А это уже другое дело. Это уже мата-алгоритм. И нет никаких препятствий в создании сколь угодно мета-алгоритма коотрый можно будет в последствии повторно использовать.

kan>Забудь о том что это буст. Перечисленные возможности по-твоему к чему относятся?

К тому что называется функциональным типов в более грамотно спроектированных языках. Все примитивы буста выражаются ими на раз по месту (без окромных и запутанных библоотек). А вот паттерны ООП — это другое дело. Их средствами ООП или ФП повторно используемыми сделать не удатстся.

kan> Это паттерн Посетитель? Или что?

Это "или что".

kan>Посмотри на SObjectizer (110000 строк кода, ну ладно, пусть на Nemerle будет в 100 раз меньше, 1100 строк), это всё ещё события?

Нет. Это сервис. Но в более гибком языке он мог бы быть библиотекой.

kan> Асинхронных событий никому не нужно? Что именно должно быть реализованно в языке?

Вообще-то в донтнете асинхронные события и так реализованы. У делегатов есть методы ассинхронного вызова. В C# правда это выглядит не очень красиво, но это вопрос сахара.

VladD2 wrote:

>> > kan>А это точно всё?
>> > Ага. Для событий все. Причем не нужно даже ядрёной енергии макросов.
>> > Просто более грамотный дизайн языка.
> kan>"640кб оперативной памяти должно быть достаточно для каждого".
> Так. Кто оставил палату номер 6 открытой?
Так выходи пока есть возможность! Погляди на белый свет!

> kan>Реализованный паттерн Посетитель это уже не паттерн, а конкретный
> алгоритм.
> Алгоритм легко реализуется функцией. Реализуй Посетителя функцией и
> поглядим. Здесь идет речь об алгоритме реализации паттерна. А это уже
> другое дело. Это уже мата-алгоритм. И нет никаких препятствий в создании
> сколь угодно мета-алгоритма коотрый можно будет в последствии повторно
> использовать.
Тебе осталось доказать, что паттерн вещь алгоритмизируемая, тогда препятствий не будет. А по-моему, это вещь
неформальная, а следовательно к каждому предложенному алгоритму может быть построен контрпример, т.е. на каждый
мета-алгоритм можно придумать применение паттерна, не учтённое этим алгоритмом. Т.е. можно будет встроить в язык
некоторый набор частных случаев применения паттерна. Однако, нельзя будет сказать, что он реализован в языке полностью.

> kan>Забудь о том что это буст. Перечисленные возможности по-твоему к
> чему относятся?
> К тому что называется функциональным типов в более грамотно
> спроектированных языках. Все примитивы буста выражаются ими на раз по
> месту (без окромных и запутанных библоотек). А вот паттерны ООП — это
> другое дело. Их средствами ООП или ФП повторно используемыми сделать не
> удатстся.
Каким образом? Скажем, упорядоченные группы вызовов? Да чтобы это в язык было встроено. Иначе, реализация "по
месту" ничем принципиально не будет отличаться от запутанных библиотек, кроме сахара.

> kan> Это паттерн Посетитель? Или что?
> Это "или что".
> kan>Посмотри на SObjectizer (110000 строк кода, ну ладно, пусть на
> Nemerle будет в 100 раз меньше, 1100 строк), это всё ещё события?
> Нет. Это сервис. Но в более гибком языке он мог бы быть библиотекой.
Да, но по сути это всё ещё реализация паттерна Visitor!

> kan> Асинхронных событий никому не нужно? Что именно должно быть
> реализованно в языке?
> Вообще-то в донтнете асинхронные события и так реализованы. У делегатов
> есть методы ассинхронного вызова. В C# правда это выглядит не очень
> красиво, но это вопрос сахара.
А в каком порядке они вызываются? Из каких нитей? Какой контекст? Что и как блокируется? И почему так, а не иначе и как
это изменить при необходимости?

Курилка wrote:

> По факту получается, что паттерны — это слишком размазанное понятие,
Не размазанное, а неформализуемое (что значит неалгоритмизируемое в общем случае), т.к. более абстрактное, чем
алгоритм/структура данных.

Здравствуйте, kan, Вы писали:

kan>Тебе осталось доказать, что паттерн вещь алгоритмизируемая, тогда препятствий не будет.

Это факт. Его описание — это алгоритм. И я тебе давал ссылку на реализацию этого паттерна, но ты ее успешно профильтровал.

Здравствуйте, WolfHound, Вы писали:

kan>>Это паттерн Посетитель? Или что?
WH>Это точно не посетитель. Ты вобще знаешь что такое посетитель и зачем он нужен?

Похоже это главный вопрос. И похоже ответ на него отрицательный. Потому и разговор весьма странный получается.

Здравствуйте, kan, Вы писали:

kan>Паттерн != алгоритм.

Ага. Это мета-алгоритм.

kan> Реализация паттерна есть алгоритм

Ага. Мета-алгоритм.

kan>(и то не всегда).

Если это не алгоритм, то это и не паттерн. Это уже черти что.

kan> Реализация алгоритма есть библиотека

Ага. А мета-алгоритма, есть мета-библиотека.

kan>или конструкция языка.

Алгоритм конструкция языка? Примеры можно?

kan> Я понимаю, что часто эти понятия путаются, чаще ради упрощения, но в данном контексте, при обсуждении сабжа — это важно различать.

Что мешает?


>> kan>Забудь о том что это буст. Перечисленные возможности по-твоему к
>> чему относятся?
>> boost::signals это жуткий мутант и ошибка природы которая должна умереть.
>> kan>Это паттерн Посетитель? Или что?
>> Это точно не посетитель.
kan>А что?

Мутировавшая реализация делегата/функции высшего порядка/события...

>> Ты вобще знаешь что такое посетитель и зачем он нужен?
kan>

In object-oriented programming and software engineering, the visitor design pattern is a way of separating an
kan>algorithm from an object structure. A practical result of this separation is the ability to add new operations to
kan>existing object structures without modifying those structures.
kan>(с) http://en.wikipedia.org/wiki/Visitor_pattern

kan>В общем почти всё. Это относится к "public MyEvent : Event[int -> void] = Event();" довольно слабо. Что именно должно
kan>поддерживаться языком?

Нда. Случай клинический. Гляжу в книгу вижу...

Перепутать паттерн Посетитель с событием — это уже перебор.

Почитай полное описание по своей ссылее. И особо обрати внимание на пример. Это как раз и есть Посетитель. Неуже ли он похож на событие?

kan>Неважно. Вопрос в другом. Ассинхронные сообщения это Event?

Эээ вообще-то нет. В дотнете ивенты — это конкретная сущность. Но их в приципе можно вызвать асинхронно.

Здравствуйте, Sinclair, Вы писали:

S>...
S>И вот это называется проще?

Это? Нет, конечно.. А вот это — да:

using System.Console;

/// Библиотечный класс. По уму еще надо создать пергруженный 
/// вариант для событий с возвращаемым значением.
public class Event[T]
{
    // Конструкторы
  public this() { _handlers = []; }
  public this(handler : T -> void) { _handlers = [handler]; }
  public this(handler : list[T -> void]) { _handlers = handler; }
  // Операторы приведения типов для инициализации по месту создания.
  public static @: (handler : T -> void) : Event[T] { Event(handler) }
  public static @: (handlers : list[T -> void]) : Event[T] { Event(handlers) }

  protected mutable _handlers : list[T -> void]; // список подключенных обработчиков событий

  public Add(handler : T -> void) : void { _handlers ::= handler; }
  public Remove(handler : T -> void) : void { _handlers = _handlers.Remove(handler) }
  /// Инициирует рассылку события. 
  public Fire(args : T) : void 
  {
    foreach (handler in _handlers)
      handler(args);
  }
}

/// Тестовый класс в котором определяются события (module == static class в C#).
module Test
{
    // Заметь, описание делегатов попросу не нужно!
  public Event1 : Event[int] = Event();
  // Инициализация по месту.
  public Event2 : Event[string * int] = (str, x) => WriteLine($"str: '$str' x: $x");

  Main() : void
  {
    Event1.Add(x => WriteLine(x));
    Event1.Fire(123);

    Event2.Fire("test", 789);
  }
}

S> Разработчикам компилятора естественно проще. К счастью, Хейльсберг больше думал о программистах, чем вы предлагаете. И встроил вот этот громоздкий паттерн в язык.

Если бы он подумал о программистах чуть болше и ввелбы, пускай не вместо, а вмесе с этим паттерном еще и возможности использованные мной при написании кода выше, то было бы еще лучше.

Согласись это выглядит очень неплохо для встроенных возможностей языка?

Собственно не сложно написать макрос который добавит возможность использования операторов += и -=, а так же макроса проверяющего что все переменные данного типа инициализированны. И все это сдерствами базового языка.

Так что выразительный язык может зачастую (скорее даже очень часто) обойтись без хардкодинга в компиляторе. И при этом он как минимум не проиграет в выразительности.

Здравствуйте, VladD2, Вы писали:

kan>>Паттерн != алгоритм.
VD>Ага. Это мета-алгоритм.

kan>> Реализация паттерна есть алгоритм
VD>Ага. Мета-алгоритм.

Мета-алгоритм это частный случай реализации одного паттерна, или любого количества паттернов, автоматизации их применения. Например, у тебя есть некий чисто декларативный язык описания паттернов, и общий движок его компиляции в код. Алгоритм движка не есть какой-то паттерн, и каждое конкретное описание паттерна на языке не является алгоритмом (потому что это просто декларация). Алгоритм движка есть мета-алгоритм по отношению к сгенерированному им коду, но ты не можешь показать ни на какой конкретный паттерн и сказать, что алгоритм движка есть его реализация, потому что движок сам по себе не реализует ни один паттерн.

Здравствуйте, VladD2, Вы писали:

VD>Если бы он подумал о программистах чуть болше и ввелбы, пускай не вместо, а вмесе с этим паттерном еще и возможности использованные мной при написании кода выше, то было бы еще лучше.

VD>Согласись это выглядит очень неплохо для встроенных возможностей языка?
Ну естественно неплохо! Влад, ты похоже потерял нить рассуждений. Речь идет о выразимости паттернов в виде конструкций. kan сомневался

Автор: kan
Дата: 26.09.06

в том, что паттерн можно выразить в языке, а уж тем более в библиотеке.
Я привел примеры того, как паттерны встраиваются в язык. Ты собственно с чем споришь? С тем, что их нужно поддерживать? Или что их нужно поддерживать при помощи Nemerle?
Вся ценность Nemerle собственно в том и состоит, что он позволяет повысить повторную используемость кода.

VD>Так что выразительный язык может зачастую (скорее даже очень часто) обойтись без хардкодинга в компиляторе. И при этом он как минимум не проиграет в выразительности.
Это здорово. Непонятно только, с чего ты решил, что я с этим спорю.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:

S>>Влад, это потребует написания класса на каждый чих. Зачем?

VD>Хороший такой чих. МС аж его захардкодил в язык и рантайм.
VD>Меж тем создать такой класс нужно ровно один раз.
Ну, в рамках .net 1.0 это пришлось бы делать ровно один раз на каждый тип делегата. Руками.
S>>В качестве упражнения: попробуй реализовать аналогичную евентам функциональность в библиотеке на C# 2.0.
VD>Синклер, ты меня извини, но ты меня с кем-то спутал. Я упражняюсь в программировании каждый день и ни в упражнениях, ни в учетелях не нуждаюсь. Более того считаю подобные предложения не корректно по отношению к другим программистам.
Почему некорректно? Ты делаешь заявления о легкости реализации чего-то другими средствами. Очевидно, что хейльсберг решил, что внесение event в язык/платформу дешевле, чем полноценная поддержка метапрограммирования. Иначе бы он изобрел Nemerle.

VD>Что касается релизации на C# 2.0, то это действительно сложно так как язык не обладает базовыми элеми необходимыми для реализации этой возможности.
Ну, вообще-то как раз на 2.0 можно написать один класс. Он, кстати, будет не многим менее удобен в использовании, чем твой вариант на Nemerle.
Я привел пример встраивания конкретного паттерна в язык. Продемонстрировав преимущества такого встраивания по сравнению с тем же языком без такого встроенного паттерна.
VD> А вот на Nemerle я тебе это реализую без особых проблем. Собственно об этом тебе и говорю.
Ты очень много говоришь, и очень мало слушаешь. В Nemerle встраивать event в язык уже не надо. Точно так же, как в С уже не надо встраивать в язык оператор вывода на консоль, в отличие от классического BASIC. И ровно по той же причине — в С есть возможность писать функции, которые реализуют ту же возможность без харкода в компилятор.

VD>Синклер, ты меня извини, но твой менторский тон мне не нравится. Или убери эту маску гуру, или давай завершим разговор.
Только после вас.

VD>Это мелкие детали. По сути это тоже свойство вид сбоку. Тебе уже скзали, что небыло бы никакой разницы если бы вместо этих спец-методов был бы некий интерфейс с думя методами.
Я вижу, мои объяснения, что это не тоже самое, не внедряются в кору головного мозга оппонентов. Ок, зайдем с другого конца: почему бы собственно свойства не выкинуть в пользу некоего интерфейса с двумя методами: set и get? Поясни, пожалуйста, cвою точку зрения.

S>> Влад, евенты встречаются в дотнете сплошь и рядом.
VD>Ага. Причем чаще всего по недаразумению и из-за отсуствия более удобных средств. Вот появится в C# 3.0 полноценная лямбда и сам увидишь, как потребность в ивентах резо уменшится.
Не понял, куда это она уменьшится. Ты не мог бы привести пример, каким образом удастся при помощи лямбды избавиться, к примеру, от AppDomain.AssemblyResolve?

S>> Инкапсуляция, очевидно, нужна для устойчивости кода к мелким ошибкам, непроверяемым компилятором.


VD>Представь, что имеется мнение отличное от твоего и представь, что твое мнение не является истиной в последней инстанции.
Вот как раз у меня-то с этим все в порядке.
VD>Причем люди могут банально иметь более широкий опыт и тем самым мыслить чуть шире.
Пока что я вижу обратный эффект. Мне заявляют "чего-то не может быть, потому что я этого не встречал". Очень сомневаюсь, что это признак широты мышления.
VD>Ты же не имея этого опыта
Очень опять же сомневаюсь, что у тебя есть возможность адекватно оценивать мой опыт.
Я кстати никаких комментариев о ширине мышления не приводил. Я просто объясняю, с какими ситуациями призван бороться определенный паттерн.

VD>>>Да и в Дельфи никогда проблем не видел.
S>>Ну конечно не видел. Евенты в дельфи были одиночными, поэтому ситуация случайного переписывания обработчика вместо добавления в список не могла возникнуть.

VD>Хм. Я мог присвоить им nil. Ты тут говорил, что это так плохо.
Нет, я не говорил, что nil это плохо. Я говорю, что отсутствие инкапсуляции приводит к тому, что можно банально забыть о том, что ты не единственный субскрайбер или просто опечататься и набрать = вместо +=. В Дельфи ты всегда был единственным субскрайбером, и поток событий был значительно проще. У тебя просто не было пяти мест вида "OnResize += HandleResize", в каждом из которых ты мог ошибиться. Если ты записал nil, то это быстро станет заметно.

VD>Я согласен, что список событий иногда удобнее. Но его нет проблем создать без хардкода.
См. VCL Source. Я уже не помню имена юнитов наизусть, но парни сделали таки без хардкода поддержку множественных подписчиков на состояние датасорсв. Ох там и кода наколбашено... А самое приятное — то, что если тебе понадобится делать множественную подписку для другого типа событий в Delphi 3-7, то ты будешь воспроизводить 1600 строк кода с нуля. По мне так это совсем не "без проблем" — лучше хардкод (а еще лучше — нормальный метапрограмминг).

VD>В общем, ивенты — это хороший сахар для ООЯ, но не было никакой необходимости хардкодить его в рантайм дотнета.
Вопрос интересный. Хейльсберг, судя по всему, посчитал паттерн Publisher-Subscriber настолько важным, что принципиально хотел его наличия совместимым образом во всех языках дотнета.
VD> А в языке можно было добавить более универсальные средства на базе которых само событие получалось бы неотличимым от встроенного.
В отдельном языке — да. Кстати, интересно: насколько сложно было бы сделать такие евенты кросс-языковыми? Чтобы в VB.NET по-прежнему можно было бы писать после имени метода handles EventBlaBla?

VD>Извини, но верить тебе у меня желания нет. Хейльсберг наделал ошибок в Дельфи и наделал их в C#. Отрадно видеть что ошибок в последнем меньше, но таки они есть и как раз мне, как постороннему наблюдателю использующему этот язык и знакомому с другими языками лучше выдны его ошибки. Ведь свои ошибки всегда видны хуже чем чужие.
Это какие например? Я в Delphi архитектурных ошибок не вижу. Его недостатки очевидным образом связаны как с ограниченными ресурсами, так и с ограниченным опытом использования.
VD>К сожалению, насколько я помню, ивенты захардкодили в рантайме дотнета.
Совершенно верно. Как и свойства. Свойства, кстати, ведь тоже наверняка можно было бы сделать на уровне библиотеки для языка с метапрограммингом (aka Nemerle)?

Здравствуйте, Klapaucius, Вы писали:

AVC>>Из всего, что я здесь прочел, напрашивается вывод, что "современными" считаются императивные языки с включением отдельных функциональных конструкций.

K>Не только. Современным может быть и чистый функциональный язык, например. Но это не важно.
K>Непонятно, кстати, почему слово "современные" Вы ставите в кавычки. Современные без всяких ковычек. Просто тенденция сейчас такая, веянье времени.

Я просто хотел отстраниться и посмотреть со стороны, без всяких оценок: "современными" принято считать языки с такими-то свойствами.
Я часто заключаю слово в кавычки, чтобы обратить на него внимание. Возможно, это не всегда уместно.
Для меня само понятие "современных языков" возникло в процессе этого обсуждения.
Ясно, что слово "современный" употребляется здесь в каком-то определенном смысле, потому что и сейчас есть люди, пишущие на Фортране, да и функциональные языки сами по себе — не такая уж новость.
Возможно, Ваша ремарка говорит о том, что Вы считаете функциональный подход в целом более современным (прогрессивным?), чем императивный?

Здравствуйте, gandalfgrey, Вы писали:

G>Если бы мы с самого начала знали, какой рынок будет у нас СЕЙЧАС...месяца за 4 написали бы. Текущая реализация написана месяца за 2.5 — но не с нуля.

Значит, серьезная неоходимость в рефакторинге еще не назрела. Дальше будет хуже, а желание делать рефакторинг руками будет все меньше и меньше.

VladD2 wrote:

> kan>или конструкция языка.
> Алгоритм конструкция языка? Примеры можно?
Тривиальные алгоритмы в основном. Скажем, map в некоторых языках, конкатенация строк. Или алгоритм обработки исключений.
Даже управляющие конструкции как while, switch/case тоже тривиальные алгоритмы. Встраивание нетривиальных алгоритмов
обычно сильно запутывает язык, так что обычно не пользуется спросом (хороший пример perl6).

>> > kan>Забудь о том что это буст. Перечисленные возможности по-твоему к
>> > чему относятся?
>> > boost::signals это жуткий мутант и ошибка природы которая должна умереть.
>> > kan>Это паттерн Посетитель? Или что?
>> > Это точно не посетитель.
> kan>А что?
> Мутировавшая реализация делегата/функции высшего порядка/события...
Ээээ. Это boost::function/boost::bind.

> kan>В общем почти всё. Это относится к "public MyEvent : Event[int ->
> void] = Event();" довольно слабо. Что именно должно
> kan>поддерживаться языком?
> Нда. Случай клинический. Гляжу в книгу вижу...
> Перепутать паттерн Посетитель с событием — это уже перебор.
> Почитай полное описание по своей ссылее. И особо обрати внимание на
> пример. Это как раз и есть Посетитель. Неуже ли он похож на событие?
Прошу прощения за невнимательность, конечно Observer.

> kan>Неважно. Вопрос в другом. Ассинхронные сообщения это Event?
> Эээ вообще-то нет. В дотнете ивенты — это конкретная сущность. Но их в
> приципе можно вызвать асинхронно.
Т.е. это не паттерн Observer из-за того, что асинхронный?

Здравствуйте, AVC, Вы писали:

K>>Современным может быть и чистый функциональный язык, например. Но это не важно.
K>>Непонятно, кстати, почему слово "современные" Вы ставите в кавычки. Современные без всяких ковычек. Просто тенденция сейчас такая, веянье времени.
AVC>Ясно, что слово "современный" употребляется здесь в каком-то определенном смысле, потому что и сейчас есть люди, пишущие на Фортране, да и функциональные языки сами по себе — не такая уж новость.
AVC>Возможно, Ваша ремарка говорит о том, что Вы считаете функциональный подход в целом более современным (прогрессивным?), чем императивный?

Я считаю, что "функциональный подход" — это просто способ декомпозиции и может ли он быть прогрессивным или современным ответить затрудняюсь. Тем более я затрудняюсь сравнивать функциональный подход с императивным, ведь по моему мнению, это вещи просто таки ортогональные. Вот декларативный "подход" с императивным я сравнить смогу. Можно, пожалуй, сказать, что декларативный в каком-то смысле прогрессивнее императивного. Но можно этого и не говорить.
Однако "прогрессивный" или "современный" все-таки не синонимы. Если понимать в хронологическом смысле, то, к примеру, чистый функциональный язык по понятным техническим причинам, не может не быть современным, хотя функциональные языки вообще, конечно, не новость. Причем под современным с хронологической точки зрения языком я подразумеваю не используемый в настоящее время, а разработанный и реализованный в настоящее время.
Понятно, что если говорить о современном только в хронологическом смысле, то разговоры о том, что должно быть в языке для того, чтобы он считался современным довольно странно. Поясняю: новые с хронологической точки зрения языки, появляющиеся в настоящее время создают некоторую конъюнктуру. Можно выделить некоторую общую для большинства из них совокупность черт, которые и позволяют судить о том, соответствует ли новый язык этой самой конъюнктуре или является анахронизмом.
Вот и все что я имею в виду, говоря о современных и несовременных языках. Надеюсь, что теперь ситуация прояснилась?

Здравствуйте, Курилка, Вы писали:

AVC>>В 7-й главе "Красного дракона" Ахо, Ульмана и Сети (в разделе Параметры-процедуры) написано:
AVC>>

AVC>>Правила лексической области видимости применимо и в том случае, когда вложенная процедура передается в качестве параметра.

AVC>>После чего идет пример именно на Паскале.
К>И что с лексической областю видимости? К ней претензий не было. Или это ты просто так для красного словца?

Нет, не для красного словца.
Просто мне показалось — мы договорились, что речь идет только о лексическом контексте.
А в Паскале вложенная процедура "помнит" о своем лексическом контексте.
Исходя из представления, что замыкание = функция + лексический контекст, я и сослался на Дракона.
В принципе, я понял, что имел в виду FR, поэтому дальнейшее выяснение вопроса выродилось бы просто в спор о словах.
Вполне можно считать, что в Паскале было "квази-замыкание", т.е. не совсем замыкание, как оно понимается в ФП.

Здравствуйте, Дарней, Вы писали:

Д>Значит, серьезная неоходимость в рефакторинге еще не назрела. Дальше будет хуже, а желание делать рефакторинг руками будет все меньше и меньше.
Видимо, я неправильно выразился. Проект существует больше года, тотальный рефакторинг проводился 2 раза. Частные вещи рефакторятся регулярно, по достижении некоей очередной стадии