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

AC>Я имел виду языки программирования в том виде в каком они есть сейчас, то есть как интерфейс человек-машина.

Ох. Ну вот посмотрите на этот форум или на какой-нибудь stackoverflow и вы увидите, как программисты, общаясь друг с другом, в свои сообщения вставляют (псевдо)код. Почему так происходит, если язык программирования — это интерфейс человек-машина?

AC>Вопрос(интересующий меня) не в "наличии последовательности вычислений",

Ну вы же пишете, что программу можно читать, как некую последовательность вычислений. А я вам объясняю, что любую программу так можно читать. Другое дело, что программу на декларативном языке можно так не читать.

AC> а в подходе который вы используете когда пишете программу, вы как бы "говорите" компьютеру:
AC>ИП — "сделай это, затем то, затем третье..."
AC>ДП — "это должно быть таким, то должно находится здесь..."

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

считаю неправильно называть его декларативным, так как программы написанные в этом стиле всё таки описывает некоторую последовательность вычисление а не "что должно получится"(как HTML например) наверняка думаете что то вроде "...эта функция возвращает значение, которое затем получает вот та функция..."

Я же говорю, что любую декларативную программу можно читать в том числе и как последовательность (точнее — последовательности) действий и HTML тоже. Никакой проблемы в этом нет, называть такую программу декларативной правильно.

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

Z>Нету тут: "Сделай, чтобы i равнялось 5" или "i должно равняться 5". Есть: 5 будем назвать i.

И что от этого принципиально поменялось?

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

S>Они не будут "свободными", они будут принадлежать или drawing context, или control context. От того, что мы заменим this явной передачей параметра ничего принципиально не изменится.

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

U>>Проблемой являются только те преобразования, которые изменяют множество разнородных сущностей.
S>+1. Грабля — такие функции могут попасться на самых разных уровнях, причём всегда внезапно. Я не теоретизирую, это одна из основных проблем с построением work tree/проектированием anemic-фреймворков, с чем я сейчас плотно работаю.

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

U>>Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.
S>Так нам придётся протаскивать по всем стеку хелперов несколько слабосвязанных параметров — начиная с геометрии рамки (она необязательно будет прямоугольной) и заканчивая кистями для рамки/фона. И писать для каждого контрола свою логику по извлечению этих параметров.

Обращение к множеству слабосвязанных параметров в отличие от их модификации не является проблемой, т.к. параметры можно передавать в виде словаря (коллекции пар ключ — значение).

К примеру, в гриде у меня параметры в ячейку передаются таким образом:

public class DevExpressCheckEditCellFiller : IGridCellFiller
{
    public static CheckEdit CreateCheckEditControl(Rectangle cellRectangle, 
      IGridColumn column, object row, object value)
    {
      CheckEdit checkBox = new CheckEdit();

      ...
      checkBox.Size = cellRectangle.Size;

      Color? backColor = SynchronizerHlp.GetBackColor(column, row);

      if (backColor != null)
        checkBox.BackColor = backColor.Value;

      checkBox.Text = SynchronizerHlp.GetCellDescription(column, row);
      ...

      return checkBox;
    }
}

  public class SynchronizerHlp
  {
    public static string GetCellDescription(IGridColumn column, object row)
    {
      Getter<string, object> descriptionGetter = column.GetExtended("CellDescription") as Getter<string, object>;
      if (descriptionGetter == null)
        return null;
      return descriptionGetter(row);
    }
  }

Где IGridColumn это по сути обертка на словарем пар ключ — параметр. Проблем никаких.

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

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

U>>>Зачем? Достаточно нужные приватные поля textBox'а передать в качестве аргументов.
S>>Так нам придётся протаскивать по всем стеку хелперов несколько слабосвязанных параметров — начиная с геометрии рамки (она необязательно будет прямоугольной) и заканчивая кистями для рамки/фона. И писать для каждого контрола свою логику по извлечению этих параметров.

U>Обращение к множеству слабосвязанных параметров в отличие от их модификации не является проблемой, т.к. параметры можно передавать в виде словаря (коллекции пар ключ — значение).
Т.е. вместо того что бы класть множество аргументов в стек (альтернатива передачи this), ты предлагаешь писать код по упихиванию их в словарь, и код, по доставанию их из словаря с проверками наличия в словаре нужных аргументов нужного типа, и отказываться от проверок времени компиляции? Опять же, словарь не гарантирует от изменений, потому передача всего этого хозяйства через словарь ничем не лучше чем вызов приватного метода с передачей всех полей через неявный this. Если все-таки надо вынести хелпер с общей функциональностью, то создание спецтипа для передачи множества аргументов будет лучшей идеей, чем словарь с хелперами по доставанию из него значений.

U>К примеру, в гриде у меня параметры в ячейку передаются таким образом:

U>

U>public class DevExpressCheckEditCellFiller : IGridCellFiller
U>

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

U>Где IGridColumn это по сути обертка на словарем пар ключ — параметр. Проблем никаких.
Переход к утиной типизации проблем никаких не приносит в условиях стабильности кода. Вот когда придется этот код агрессивно менять, и если такого кода окажется достаточно много — вот тогда они придут.

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

S>Т.е. вместо того что бы класть множество аргументов в стек (альтернатива передачи this), ты предлагаешь писать код по упихиванию их в словарь, и код, по доставанию их из словаря с проверками наличия в словаре нужных аргументов нужного типа, и отказываться от проверок времени компиляции? Опять же, словарь не гарантирует от изменений, потому передача всего этого хозяйства через словарь ничем не лучше чем вызов приватного метода с передачей всех полей через неявный this. Если все-таки надо вынести хелпер с общей функциональностью, то создание спецтипа для передачи множества аргументов будет лучшей идеей, чем словарь с хелперами по доставанию из него значений.

В случае необходимости передачи большого количества параметров возможны три ситуации:

1) Все реализации интерфейса требуют одного и того же набора обязательных параметров. Создаем структуру данных в виде обычного типа с полями и свойствами и передаем ее всем реализациям. Проблем никаких.

2) Каждая реализация интерфейса требует своего набора опциональных параметров. Если параметр опциональный, то, значит, он имеет значение по умолчанию, соответственно если в словаре значения нет, то мы это значение по умолчанию и используем. Проблем никаких.

3) Каждая реализация интерфейса требует своего набора обязательных параметров. В этом случае метод конструировния реализации принимает строго типизированный набор параметров, передавая их далее как словарь. Например, в данном случае вместо new GridColumn(...).CellFiller(CheckCellFiller.Default).BackColor(Color.Wheat) используем CheckCellFiller.CreateColumn(Color.Wheat). Что гарантирует, что мы никакие нужные параметры указать не забудем. Опять же проблем никаких.

Так в каких случаях передача большого количества параметров является проблемой?

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

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

S>>Т.е. вместо того что бы класть множество аргументов в стек (альтернатива передачи this), ты предлагаешь писать код по упихиванию их в словарь, и код, по доставанию их из словаря с проверками наличия в словаре нужных аргументов нужного типа, и отказываться от проверок времени компиляции? Опять же, словарь не гарантирует от изменений, потому передача всего этого хозяйства через словарь ничем не лучше чем вызов приватного метода с передачей всех полей через неявный this. Если все-таки надо вынести хелпер с общей функциональностью, то создание спецтипа для передачи множества аргументов будет лучшей идеей, чем словарь с хелперами по доставанию из него значений.

U>В случае необходимости передачи большого количества параметров возможны три ситуации:

U>1) Все реализации интерфейса требуют одного и того же набора обязательных параметров. Создаем структуру данных в виде обычного типа с полями и свойствами и передаем ее всем реализациям. Проблем никаких.
Передаем параметры спецтипом. А что за интерфейс-то? Речь шла о "свободных" функциях и передачи в них аргументов, разве нет?

U>2) Каждая реализация интерфейса требует своего набора опциональных параметров. Если параметр опциональный, то, значит, он имеет значение по умолчанию, соответственно если в словаре значения нет, то мы это значение по умолчанию и используем. Проблем никаких.
отличий от случая 1) никаких, т.к. он тоже может обрабатывать опциональные параметры с помощью соответствующих полей/свойств/автосвойств в структуре данных. А зачем словарь? Какую проблему он решает?

U>3) Каждая реализация интерфейса требует своего набора обязательных параметров. В этом случае метод конструировния реализации принимает строго типизированный набор параметров, передавая их далее как словарь. Например, в данном случае вместо new GridColumn(...).CellFiller(CheckCellFiller.Default).BackColor(Color.Wheat) используем CheckCellFiller.CreateColumn(Color.Wheat). Что гарантирует, что мы никакие нужные параметры указать не забудем. Опять же проблем никаких.
Только словарь зачем?

U>Так в каких случаях передача большого количества параметров является проблемой?
Большое количество параметров является проблемой само по себе, т.к. требует написания спецкода по их передаче, усложняет рефакторинг. Спецтип для передачи аргументов проблему некоторым образом решает, но приводит либо к изобилию спецтипов, либо к озвученной проблеме, когда непонятно, что именно для какого метода нужно передавать, и что будет изменено внутри вызова.
Безотносительно конкретного примера с гридом, словарь в общем случае ничего не упрощает, только добавляет необходимость в хелперах, достающих и кастующих значения из него.

Здравствуйте, samius, Вы писали:
S>А есть такая цель? Если ты разработчик этого класса — открой код. Если пользователь — кури доку.
U>>, ни использовать его функциональность в другом классе.
S>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.
Зато от переноса .Skip из List в extension для IEnumerable толку будет очень много. Потому, что мы одним махом написали Skip, который подходит ко всем коллекциям, а не только к List.
Речь-то идёт о том, чтобы освободить те функции, которым не особо нужно быть связанными.
Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.

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

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

AC>>Здравствуйте, MasterZiv, Вы писали:
MZ>>>-- что делать
MZ>>>-- как делать

AC>>Упаковываем "как делать" в например процедуры и у нас остаётся только "что делать".

G>Не всегда. Процедуры могут неявно менять состояние и будет только иллюзия декларативности.
"Торописса не надо" — надо научиться их правильно готовить...

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

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

S>>Если можно вынести что-то вроде Array.Resize, то это как-правило выносится. А от выноса List<T>.Capacity в SetListCapacity<T>(ref T[] listUnderlyingArray, ref int listCapacity, int newCapacity), как правило, толку не будет в другом классе.
S>Зато от переноса .Skip из List в extension для IEnumerable толку будет очень много. Потому, что мы одним махом написали Skip, который подходит ко всем коллекциям, а не только к List.
S>Речь-то идёт о том, чтобы освободить те функции, которым не особо нужно быть связанными.
Я же написал (см выделенное).
Вообще я не до конца понимаю о чем именно идет речь. Терминов "свободный" и "связанный" применительно к функциям я не встречал. Формального определения не видел. Интуитивно я догадываюсь, о чем речь, но боюсь, что могу и ошибаться со своими догадками.

Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.
Я не вижу смысла тащить в класс функции, которые там могут и не быть, как и наоборот, не вижу смысла тащить из класса то, что от него сложно отделяется. Выношу все что выносится, но без садо-мазы.
В дискуссию я влез потому что увидел странное для меня употребление чистоты и детерминированности, не предполагая, что речь идет о выносе/не выносе.
S>Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.

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

S>Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.
S>Я не вижу смысла тащить в класс функции, которые там могут и не быть, как и наоборот, не вижу смысла тащить из класса то, что от него сложно отделяется. Выношу все что выносится, но без садо-мазы.
S>В дискуссию я влез потому что увидел странное для меня употребление чистоты и детерминированности, не предполагая, что речь идет о выносе/не выносе.
S>>Причём это никак не противоречит идее иметь в LinkedList свой Skip, который по производительности эффективнее стандартного.
Да, с точки зрения терминов и определений тут какой-то бардак.

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

U>>можно сделать вывод, что функции должны быть "исключительно" свободными?
S>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.

Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же. Уникальная трактовка инкапсуляции, ничего не скажешь. Похоже, паттерны растут именно отсюда

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

S>Для меня вопрос освобождения функций, которым не особо нужно быть связанными, не стоит. Обычно я сначала прикидываю, обойдется ли функция публичным интерфейсом класса. Если да, она будет извне. Если ее при этом можно обобщить — она будет обобщена. Skip хорошо обобщается и ему (обобщенному) не нужны внутренности класса. Наоборот, List<T>.Capacity не обобщается и для его выноса нужно мудрить.
S>Я не вижу смысла тащить в класс функции, которые там могут и не быть, как и наоборот, не вижу смысла тащить из класса то, что от него сложно отделяется. Выношу все что выносится, но без садо-мазы.
S>В дискуссию я влез потому что увидел странное для меня употребление чистоты и детерминированности, не предполагая, что речь идет о выносе/не выносе.

"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин

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

AC>Много рас здесь встречал высказывания типа "императивный код — фее..."
AC>Но ведь мы используем этот подход повсеместно в жизни(когда планируем что то или делаем), чем по вашему мнению он плох применительно к программированию?

Он не плох и не хорош

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

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

S>>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.

I>Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же.
ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.

I>Уникальная трактовка инкапсуляции, ничего не скажешь. Похоже, паттерны растут именно отсюда
Не уникальнее твоей

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

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

I>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин
Если так, то наверное тебя не затруднит привести пару ссылок на то, что устоялось под этим термином?

В контексте данного топика его не так давно подобрали

Автор: Undying
Дата: 22.07.11

, что бы он успел устояться.

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

I>>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин
S>Если так, то наверное тебя не затруднит привести пару ссылок на то, что устоялось под этим термином?

Букварь:
http://www.google.com/search?q=%D1%81%D0%BA%D0%BE%D1%82%D1%82+%D0%BC%D0%B5%D0%B9%D0%B5%D1%80%D1%81+%D1%81%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5+%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8&amp;sourceid=ie7&amp;rls=com.microsoft:en-us:IE-Address&amp;ie=&amp;oe=

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

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

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

S>>>С "исключительно" я перегнул. Но мне кажется и с львиной ты тоже. Если даже взять одни только штатные коллекции, то львиную долю функциональности вынести в свободные функции не получится. Потоки/файлы — нет. Строки и текст — нет. Контролы — тоже нет. Более менее свободен лишь Math.

I>>Уже получилось. Linq 2 Objects например И с потомками, и со строками, и с контролами точно так же.
S>ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.

Было
"если львиную долю функциональности держать в свободных функциях,"
ты тут же передёрнул
"львиную долю функциональности вынести в свободные функции не получится"

Ничего нового

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

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

I>>>"разве что делать его свободным совсем не обязательно" — свободная функция вообще говоря сильно устоявшийся термин
S>>Если так, то наверное тебя не затруднит привести пару ссылок на то, что устоялось под этим термином?

I>Букварь:
I>http://www.google.com/search?q=%D1%81%D0%BA%D0%BE%D1%82%D1%82+%D0%BC%D0%B5%D0%B9%D0%B5%D1%80%D1%81+%D1%81%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5+%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8&amp;sourceid=ie7&amp;rls=com.microsoft:en-us:IE-Address&amp;ie=&amp;oe=

Ты уверен что Undying подразумевал под термином "свободный" non-member non-friend?

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

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

S>>ты как всегда, с места и сразу в лужу. Когда говорят о выносе, то обычно подразумевают что нечто в одном месте убывает и в другом появляется. В случае с Linq 2 Objects выноса не произошло. Его достроили сбоку. Причем, практически ничего даже продублировано не оказалось.

I>Было
I>"если львиную долю функциональности держать в свободных функциях,"
I>ты тут же передёрнул
I>"львиную долю функциональности вынести в свободные функции не получится"

Ты забыл процитировать "а функции классов сводить к вызовам свободных функций при минимуме дополнительной логики."

I> Ничего нового
Что ты за птица, что бы тебя удивлять чем-то новым?

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

I>>"если львиную долю функциональности держать в свободных функциях,"
I>>ты тут же передёрнул
I>>"львиную долю функциональности вынести в свободные функции не получится"

S>Ты забыл процитировать "а функции классов сводить к вызовам свободных функций при минимуме дополнительной логики."

"держать" != "выносить" и дальше от тебя уже пошла подмена. А твоя цитата здесь ничего не меняет.