Как вам задумка, а? - Открытые проекты

Здравствуйте, <Аноним>, Вы писали:
Не удержался. Уж очень мне жалко всех тех, кто упорно пытается честно идти на поводу у автора постинга и заниматься конструктивной критикой непонятно чего.
Уважаемый аноним, на ваш запрос невозможно дать никакого полезного ответа. Вы тщательно написали о том, чего НЕ будет в вашей мегасреде. Очень хорошо. А что будет взамен? Про это ничего по существу не сказано — какие-то туманные намеки.
Поэтому все обсуждение сводится к:
— критике выбрасывания полезных, по мнению народа, вещей (строчек кода)
— критике того, как критик представляет себе реализацию Ваших туманных намеков.

Поэтому Вам я крайне рекомендую просто взять и запостить пару скриншотов. Ведь для этого достаточно MS Paint и свободного вечера, не так ли? Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет:
http://www.codeproject.com/useritems/Visual_Studio_2020.asp
Покажите мне, как будет выглядеть вот этот простенький код в вашей мегасреде:

public static IEnumerable<T> Filter<T>(IEnumerable<T> source, Predicate<T> predicate)
{
  foreach(T item in source) 
        if (predicate(item))
            yield return item;
}

Тогда я, к примеру, смогу задать еще парочку уточняющих вопросов.
Вообще, для справки: когда вы предлагаете решение некой задачи, для его обоснования нужно сделать буквально следующее:
1. Описать типичную задачу, которую предполагается решать
2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах)
3. Описать типичные шаги, которые надо будет выполнить в вашем решении.

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

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

1.1.4 stable rev. 510

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

LX>Уважаемый Аноним.
LX>Как вы уже, наверно, поняли в вашу идею мало кто верит, но вы по прежнему доказываете, что она верна и выведет программирование на новый уровень, почему бы вам просто не выложить в вашу идею в виде готового решения и попросить всех заценить реализацию идеи.
LX>И после этого, думаю, можно 100% будет кто был прав, а кто нет, но пока этого нет весь разговор пустой трёп. Все карты вам в руки.

Я прекрасно понимал всё это. Ещё до того, как я запостил эту тему, все мои знакомые высказывались против, точнее они не понимали идею вообще. Никто из них не сказал, что я изобретаю велосипед! Они просто недопонимали саму идею. Так что я готов к непониманию...

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

LX>Если не затруднит, напишите пожалуйста драйвер для видеокарты. (видеокарта на ваш вкус).
LX>Либо создайте аналог линуховской LILO (программа, которая будет позволять выбирать ОС для загрузки)

Хех, я вообще-то имел в виду прикладное ПО.

S>Поэтому все обсуждение сводится к:
S>- критике выбрасывания полезных, по мнению народа, вещей (строчек кода)
S>- критике того, как критик представляет себе реализацию Ваших туманных намеков.

Жаль только, что критики плохо представляют себе мою реализацию. Может быть, потому что я недостаточно внятно её объяснил.
Впрочем, всё то, что сейчас говорится, тоже весьма интересно лично мне.
Кстати мне и только мне судить о полезности всех этих рассуждений, т.к. это именно то, рали чего я запостил эту тему.

S>Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет:

Я думаю, раньше

S>Покажите мне, как будет выглядеть вот этот простенький код в вашей мегасреде:
S>

S>public static IEnumerable<T> Filter<T>(IEnumerable<T> source, Predicate<T> predicate)
S>{
S>  foreach(T item in source) 
S>        if (predicate(item))
S>            yield return item;
S>}
S>

Это у вас "простенький" код?

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

S>Вообще, для справки: когда вы предлагаете решение некой задачи, для его обоснования нужно сделать буквально следующее:
S>1. Описать типичную задачу, которую предполагается решать
S>2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах)
S>3. Описать типичные шаги, которые надо будет выполнить в вашем решении.

Ну это просто.

1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его
2. решение на C# (пишется в блокноте

START:
foreach (int key in idict.Keys)
{
  if (idict [key] < 0)
  {
    idict.Remove (key);
    goto START;
  }
}

собственно для этого решения необходимо только набрать эти строчки кода
3. решение в моей среде (типа это дерево вроде TreeView):

<method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
| // тело метода
-- <instruction 1> foreach {int key, idict.Keys}
   | // тело цикла
   -- <instruction 1> if {idict [key] < 0}
      | // тело условия
      -- <instruction 1> idict.Remove {key}

для этого решения достаточно в 2х диалоговых окнах (а в будущем — боковых панелях, так будет удобнее) выбрать параметры 3х операций — foreach, if и call.

Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.

Вообще структура проще при манипулировании.

Здравствуйте, <Аноним>, Вы писали:

А>Жаль только, что критики плохо представляют себе мою реализацию. Может быть, потому что я недостаточно внятно её объяснил.
Совершенно верно. Объясняйте как можно подробнее — иначе нечего критиковать.
S>>Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет:
А>Я думаю, раньше

На самом деле да. Часть из этих идей будет реализована уже в ближайшие 3-5 лет.

А>Это у вас "простенький" код?

Конечно. Он прекрасно читается, легко пишется, и превосходен в использовании.

А>Должен огорчить любителей генериков — в первой версии их не будет. Я думаю, я их не буду поддерживать вообще. Вместо них я лучше сделаю другой механизм, но похожий, не на уровне языка, а на уровне абстрагированной структуры проекта.
Ха-ха. Ладно, фиг с ними, с генериками.

А>Ну это просто.

А>1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его
А>2. решение на C# (пишется в блокноте

):
А>

А>START:
А>foreach (int key in idict.Keys)
А>{
А>  if (idict [key] < 0)
А>  {
А>    idict.Remove (key);
А>    goto START;
А>  }
А>}
А>

Ну, для пущей педантичности приведем более "правильное" решение(приведенный код нарушает мое внутреннее эстетическое чувство, кроме того, его быстродействие на больших словарях просто отвратительно):

List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
  if (idict[key] < 0)
    idict.Remove(key);

А>собственно для этого решения необходимо только набрать эти строчки кода
Совершенно верно. Причем среда с Code Completion помогает набирать код, примерно вдвое сокращая количество нажатий на кнопки.
А>3. решение в моей среде (типа это дерево вроде TreeView):
А>

А><method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
А>| // тело метода
А>-- <instruction 1> foreach {int key, idict.Keys}
А>   | // тело цикла
А>   -- <instruction 1> if {idict [key] < 0}
А>      | // тело условия
А>      -- <instruction 1> idict.Remove {key}
А>

А>для этого решения достаточно в 2х диалоговых окнах (а в будущем — боковых панелях, так будет удобнее) выбрать параметры 3х операций — foreach, if и call.
Начинаем докапываться:
1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло.
2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?
3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов.
Так что давайте поподробнее — прямо в элементарных действиях. Типа "правый клик, выбираем New>, ждем ~50 секунд, пока система подгрузит список доступных операций, ...

А>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
А>Вообще структура проще при манипулировании.
Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько

1.1.4 stable rev. 510

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

А>>1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его
А>>2. решение на C# (пишется в блокноте

):
А>>

А>>START:
А>>foreach (int key in idict.Keys)
А>>{
А>>  if (idict [key] < 0)
А>>  {
А>>    idict.Remove (key);
А>>    goto START;
А>>  }
А>>}
А>>

S>Ну, для пущей педантичности приведем более "правильное" решение(приведенный код нарушает мое внутреннее эстетическое чувство, кроме того, его быстродействие на больших словарях просто отвратительно):

S>

S>List<int> keys = new List<int>(idict.Keys);
S>foreach (int key in keys)
S>  if (idict[key] < 0)
S>    idict.Remove(key);
S>

Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.

S>Начинаем докапываться:
S>1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло.

GUI ещё не рабочее. Представьте себе элемент TreeView, у которого в узлах — вот эти строчки. Т.е. приведённые строчки сгенерированны ядром среды, а не программистом! Программист только задал параметры.

S>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?

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

S>3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов.

Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё.

S>Так что давайте поподробнее — прямо в элементарных действиях. Типа "правый клик, выбираем New>, ждем ~50 секунд, пока система подгрузит список доступных операций, ...

Кстати, список доступных операций грузится при загрузке среды за ~10 секунд (иногда даже меньше).
В принципе, будет так как вы и сказали. Только не правый клик, а выбор в боковой панели из красивого такого списка (точнее это тоже будет дерево, группированное по категориям инструкций, например: элементарные инструкции, окна, файловая система, сокеты, консоль и т.д.).
Далее появляется окно свойств выбранной инструкции, где можно указать параметры для конкретной инструкции (для if — условие, для for — первое значение, условие выхода, значение инкремента и т.п.).

А>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
S>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?

Да потому что я заложил в него это!

А>>Вообще структура проще при манипулировании.
S>Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько

Вы не поняли! Я говорю при манипулировании!!! Т.е. при изменении параметров инструкций, имён (клавишей F2), и т.д. и т.п. Понимаете, о чём я? Это же всё автонастраиваемые объекты! Т.е. я могу взять из приведённого примера скопировать foreach, затем вставить его в другой метод, у которого аргумент — тоже реализует IDictionary и всё, этот же код будет работать в другом методе без исправлений. Это как пример.

Здравствуйте, <Аноним>, Вы писали:

А>А теперь критику и мнения в студию!

Что-то это всё сильно смахивает на тролля из fido, больно похожа и техника, и пафос ...

С Уважением, Andir!

using( RSDN@Home 1.2.0 alpha rev. 652 ) { /* Работаем */ }

Здравствуйте, <Аноним>, Вы писали:

А>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.

А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта).

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, <Аноним>, Вы писали:

А>>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
S>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
А>Да потому что я заложил в него это!

Ну это ты положим заложить можешь. А если представить следующий случай

List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
    MegaLib.MegaClass.MegaMethod(idict, key);

Причем MegaLib это сборка реализованая на C# (допустим) и исходниеков к ней нет. И внутри MegaLib.MegaClass.MegaMethod или луче не этого метода а метода который вызывает этот метод и так еще раз 5-6 комуто стукнуло грохнуть элемент key. Как твой генератор должен об этом догадываться? Причем это наверняка не самый сложный случай.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Здравствуйте, <Аноним>, Вы писали:

А>>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.

ДА>А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта).

Express Edition меня не вдохновляет. У меня есть Professional Edition. Проц у меня 800 MHz, памяти 512 и при этом всём тормозит.

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Здравствуйте, <Аноним>, Вы писали:

А>>>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
S>>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
А>>Да потому что я заложил в него это!

ДА>Ну это ты положим заложить можешь. А если представить следующий случай

ДА>

ДА>List<int> keys = new List<int>(idict.Keys);
ДА>foreach (int key in keys)
ДА>    MegaLib.MegaClass.MegaMethod(idict, key);
ДА>

ДА>Причем MegaLib это сборка реализованая на C# (допустим) и исходниеков к ней нет. И внутри MegaLib.MegaClass.MegaMethod или луче не этого метода а метода который вызывает этот метод и так еще раз 5-6 комуто стукнуло грохнуть элемент key. Как твой генератор должен об этом догадываться? Причем это наверняка не самый сложный случай.

Так ведь структуру проекта создаёт программист! Если я правильно понял пример, то здесь будет несколько вложенных инструкций call. Это программист задаст сам в так называемом моём "построителе выражений" (аналог можно найти в MS Access). А уж построить код по схеме — раз плюнуть для генератора.

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

A>Здравствуйте, <Аноним>, Вы писали:

А>>А теперь критику и мнения в студию!

A>Что-то это всё сильно смахивает на тролля из fido, больно похожа и техника, и пафос ...

Нет, я не из фидо и не был там никогда. Хотя иногда жалею об этом.

Здравствуйте, <Аноним>, Вы писали:

А>>>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.
ДА>>А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта).
А>Express Edition меня не вдохновляет. У меня есть Professional Edition.

Зря помоему. Если с VS2003 сравнивать так и в Express есть все что надо.

А>Проц у меня 800 MHz, памяти 512 и при этом всём тормозит.

На 800 не работал. Работал на 1.1 Pentium 3, но памяти 192 (На WinXP). Переключение в дизайнер конечно притормаживает, но вобще ничего. Памяти нехватало так как комп из свопа практически не выбирался.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, <Аноним>, Вы писали:

А>Так ведь структуру проекта создаёт программист! Если я правильно понял пример, то здесь будет несколько вложенных инструкций call. Это программист задаст сам в так называемом моём "построителе выражений" (аналог можно найти в MS Access). А уж построить код по схеме — раз плюнуть для генератора.

Не правильно ты понял — call здесь будет один. MegaMethod статический метод класса MegaClass расположенного в пространстве имен MegaLib. Но это так мелочи. С примером я немного накасячил, вот то что хотел спросить:

Твое представление:

<method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
| // тело метода
-- <instruction 1> foreach {int key, idict.Keys}
   | // тело цикла
   -- <instruction 1> MegaLib.MegaClass.MegaMethod{idict, key}

Варианты реализации:

Вариант 1 (idict не модифицируется внутри метода)

foreach (int key in idict.Keys)
{
    MegaLib.MegaClass.MegaMethod(idict, key);
}

Вариант 2 (idict модифицируется внутри метода)

List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
    MegaLib.MegaClass.MegaMethod(idict, key);

S>>>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
А>>>Да потому что я заложил в него это!

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, <Аноним>, Вы писали:
А>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!!
Во-первых, не суть важно. Можно переписать код и без дженериков. Просто так — короче, а мне не хотелось засорять пример лишним кодом.
А>А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК.
Ну что я могу сказать? Ты берешься сделать инструмент лучше всех на свете, и при этом сознательно игнорируешь передовые достижения IDE-шной мысли.
А>Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.
S>>Начинаем докапываться:
S>>1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло.
А>GUI ещё не рабочее.
Paint работает? Вперед! Еще раз тебе повторяю: если ты не можешь нарисовать GUI в Paint, то программу для его рисования ты тем более никогда не напишешь!
S>>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?
А>Нет, почему же, ещё нужно. Но достаточно выбрать скажем элемент foreach из списка доступных инструкций
Ок. Огласите, пжалста, весь список.
Этот список — он где? В меню? Откуда мы достаем это меню? По правой кнопке на узле твоего дерева? Или Insert->Statement->...?
А>и натравить его на на что-то, что поддерживает IEnumerable
О! Что значит "натравить"? Где мы возьмем это что-то, что поддерживает IEnumerable? Напомню, что OOUI требует наличия объекта действия прямо на экране. Ты можешь оценить, сколько объектов, реализующих IEnumerable, может быть в области видимости вставляемого стейтмента?
А>- вот инструкция готова (придётся указать только тип элементов, в нашем случае — int).
S>>3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов.
А>Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё.

C точки зрения UI 10000 — это то же самое, что и бесконечность. Ты не пробовал посчитать количество публичных типов в стандартных сборках FCL, которые как правило включены в проект?
А>Кстати, список доступных операций грузится при загрузке среды за ~10 секунд (иногда даже меньше).
А>В принципе, будет так как вы и сказали. Только не правый клик, а выбор в боковой панели из красивого такого списка (точнее это тоже будет дерево, группированное по категориям инструкций, например: элементарные инструкции, окна, файловая система, сокеты, консоль и т.д.).
Отлично. Сколько кликов нужно сделать в этой панели, чтобы найти доступную операцию?
А>Далее появляется окно свойств выбранной инструкции, где можно указать параметры для конкретной инструкции (для if — условие, для for — первое значение, условие выхода, значение инкремента и т.п.).

S>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
А>Да потому что я заложил в него это!

Отлично. И сколко еще таких хаков ты предполагаешь заложить в свою среду? Как предполагается расширять эти знания?

А>>>Вообще структура проще при манипулировании.
S>>Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько
А>Вы не поняли! Я говорю при манипулировании!!!
Я-то как раз всё понял.
А>Т.е. при изменении параметров инструкций, имён (клавишей F2), и т.д. и т.п. Понимаете, о чём я?
Понимаю. Это называется рефакторинг, и прекрасно работает в существующих средах. Например, в VS 2005, IntelliJ IDEA, и даже в VS 2003 + Resharper.
А>Это же всё автонастраиваемые объекты! Т.е. я могу взять из приведённого примера скопировать foreach, затем вставить его в другой метод, у которого аргумент — тоже реализует IDictionary и всё, этот же код будет работать в другом методе без исправлений.
Во-первых, в реальной программе фрагментов кода, которые надо скопировать без изменений, не бывает. А если они есть, то это повод почистить конюшни, образовавшиеся в результате полета творческой мысли. А ты что, правда каждый раз пишешь этот чудовищный код удаления из словаря? Подсказка: правильные пацаны пишут статик метод ClearDictionary(...) и больше никогда об этом не думают.

Во-вторых, совсем без переделок не обойдется. Ведь в целевом методе скорее всего другие агрументы! И тебе как минимум придется настроить foreach: выбрать аргумент для перебора.
В итоге объем затрат сравним с обычным copy-paste, в котором тоже достаточно подправить аргумент in. Причем с учетом code completion это может потребовать меньше нажатий кнопок, чем твой выбор из списков.
А>Это как пример.
Ну, пока что пример неудачный.

1.1.4 stable rev. 510

Здравствуйте, Дьяченко Александр, Вы писали:

ДА>Твое представление:

ДА><method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
ДА>| // тело метода
ДА>-- <instruction 1> foreach {int key, idict.Keys}
ДА>   | // тело цикла
ДА>   -- <instruction 1> MegaLib.MegaClass.MegaMethod{idict, key}
ДА>

ДА>Варианты реализации:

ДА>Вариант 1 (idict не модифицируется внутри метода)

ДА>foreach (int key in idict.Keys)
ДА>{
ДА>    MegaLib.MegaClass.MegaMethod(idict, key);
ДА>}
ДА>

ДА>Вариант 2 (idict модифицируется внутри метода)

ДА>List<int> keys = new List<int>(idict.Keys);
ДА>foreach (int key in keys)
ДА>    MegaLib.MegaClass.MegaMethod(idict, key);
ДА>

ДА>На основе чего твой генератор будет выбирать вариант преобразования твоего представления в код? (напоминаю MegaLib отдельная сборка исходников к ней нет).

Если вы имеете в виду, откуда он знает, изменится словарик в методе или нет — так он этого и не знает. Это ж не ИИ. Просто в окне соответствующей инструкции foreach будут галочки типа "Перезапускать перечисление после изменения коллекции" (будет автоматически установлена, если в теле цикла будет найдена инструкция, явно изменяющая коллекцию, которую перечисляем) и "Выходить из цикла после изменения коллекции". Т.е. вызов idict.Remove (...) полюбому будет считатся изменением коллекции. А вызов MegaMethod — нет. Программист сам должен это знать.

Блин, да вы наверно подумали, что я тут типа ИИ пишу! Нет, не ИИ. Пока, по крайне мере...

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

S>Ну что я могу сказать? Ты берешься сделать инструмент лучше всех на свете, и при этом сознательно игнорируешь передовые достижения IDE-шной мысли.

Ничего не знаю. И на VS2003 можно написать VS2010.

S>Paint работает? Вперед! Еще раз тебе повторяю: если ты не можешь нарисовать GUI в Paint, то программу для его рисования ты тем более никогда не напишешь!

Не смешите меня.

S>>>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?
А>>Нет, почему же, ещё нужно. Но достаточно выбрать скажем элемент foreach из списка доступных инструкций
S>Ок. Огласите, пжалста, весь список.

Я устану его оглашать здесь, ибо он займёт несколько страниц.

S>Этот список — он где? В меню? Откуда мы достаем это меню? По правой кнопке на узле твоего дерева? Или Insert->Statement->...?

Нет, этот список в виде красивого дерева в боковой панели главного окна.

А>>и натравить его на на что-то, что поддерживает IEnumerable
S>О! Что значит "натравить"? Где мы возьмем это что-то, что поддерживает IEnumerable? Напомню, что OOUI требует наличия объекта действия прямо на экране. Ты можешь оценить, сколько объектов, реализующих IEnumerable, может быть в области видимости вставляемого стейтмента?

А зачем в пределах видимости???? Вы что, считаете меня совсем за идиота, да? Что такое drag&drop, знаем? Ну так вот. Есть допустим локальная переменная. Мы перетаскивает инструкцию foreach из той самой панели на узел дерева в коде, придствавляющий эту переменную. При этом если эта переменная не поддерживает IEnumerable, то курсор мыши будет значком запрета.

А>>Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё.
S>

Отлично. И сколко еще таких хаков ты предполагаешь заложить в свою среду? Как предполагается расширять эти знания?

Много. А расширять... ну так база данных есть для этого. И редактор этой базы данных.

S>Во-вторых, совсем без переделок не обойдется. Ведь в целевом методе скорее всего другие агрументы! И тебе как минимум придется настроить
S>foreach: выбрать аргумент для перебора.

Нет, не придётся, если аргумент-коллекция только один.

В общем, товарищу Анониму стоит поработать хоть раз с Class Designer, ну тем, что вместе с его Visual Studio 2005 Professional Edition идет. Типа представь несложную изолированную часть проекта... Дюжина классов, пара-тройка интерфейсов, в общей сложности штук сто методов, свойств и событий. Попробуй набросать такую структуру из кода (как все привыкли делать в Visual Studio 2003 и ранее), а потом то же самое из Class Designer. Теперь еще попробуй все это дело задокументировать. Сам сегодня увлекался и следил за производительностью. Пример (в красках):

* Нужно документировать свойство. Если пишем руками, то: нажимает три раза слеш (секунда в худшем случае), пишем комментарий и вставляем теги при помощи Intellisense. Если действуем из Class Designer. Позиционируемся на окно Properties, позиционируемся на строчку Summary, позиционируемся на кнопку "...", нажимаем ее, позиционируемся на текстовое поле Summary, вбиваем туда подсказку без помощи Intellisense, позиционируемся на кнопку Ok, нажимаем кнопку Ok. Ну как? Думаешь, сколько времени займет overhead? А ты попробуй, ты же у нас на слово не веришь.

* Нужно унаследовать класс от интерфейса. Если действуем из кода. Переводим курсор за имя класса. Одна секунда. Нажимаем двоеточие и вбиваем имя интерфейса с помощью Intellisense. Еще секунда. Ну две. Наводим курсор на интерфейс, жмем в меню Implement interface. Еще две секунды. Итого 5 (пять) секунд. Далее мы пытаемся проделать то же самое из Class Designer. Позиционируеся на Toolbox . Одна секунда. Позиционируемся за кнопку Inheritance и нажимаем ее. Еще секунда. Теперь позиционируемся на класс. Три секунды, потому что его необходимо еще где-то найти визуально (а вдруг он у нас за экран вылез, тогда еще и покрутить лифты). Далее мы зажимаем левую кнопку мыши и тащим к интерфейсу, на визуальное отыскание которого уходит еще секунды три + время на перетасивание указателя на тело интерфейса. Дельту сам посчитаешь? Сюда еще добавим субъективную скорость, которая играет очень важную роль при оценке юзабилити и удобство при работе. А с клавиатуры лично мне все эти вещи производить куда как комфортнее... Хотя бы потому, что физически менее затратно. Что проще: пальцами клавиши давить, или мышь по всему столу таскать и постоянно переносить одну руку с мыши на клаву? А мне, как любителю работать с ноута, так и вообще мрак.

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

Две капли морфия облегчат тебе жизнь.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

	От:	Аноним
	Дата:	25.09.06 05:07
	Оценка:

	От:	Аноним
	Дата:	25.09.06 05:13
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	25.09.06 06:39
Оценка:	+1

	От:	Аноним
	Дата:	25.09.06 06:39
	Оценка:

	От:	Аноним
	Дата:	25.09.06 06:40
	Оценка:

От:	Andir	http://twitter.com/AndirNotes
Дата:	25.09.06 11:03
Оценка:

	От:	Дьяченко Александр
	Дата:	25.09.06 11:46
	Оценка: