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

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

VD>>>Ведь даже "инжект" это уже детали реализации паттерна сложения элементов который еще нужно угатадать.

E>>Как раз "инжект" -- это не паттерн сложения. По крайней мере в Ruby, который inject позаимствовал из Smalltalk. В качестве inject-а может быть и произведение элементов.

VD>Как ты там мне говорил? Учисть читать что написал...
+1


Наверное, нужно было написать "не реализация паттерна сложения".

VD>В общем, обрати внимание на выделенное жирным. Я имею в виду, что в коде используется паттерн "сложнеие", а через "инжект" он реализован или через "форич" уже не так важно. В коде уже детали реализации, а не абстракция сложения. Если хочешь чтобы код был максимально понятно, то нужно все такие места (ну, до разумных приделов) выделить в отдельные функции. Провести, тык-сызать, функциональную декомпозиции.

Все это так, только сказанное тобой в полной мере относится и к for, и к foreach, и к inject. Если в коде выполняется сложение чего-нибудь, то хотелось бы видеть sum, если перемножение -- то product, если подсчет вхождения какого-то элемента -- то count_of. Если же готовой функции на конкретную операцию нет (либо про нее не знаем), то у нас есть выбор -- написать прямо в коде коротенький for (foreach, inject), либо написать рядом функцию с нужным именем, а затем ее вызываем. Почему-то часть людям проще написать for, чем функцию и ее вызов. И вот здесь я не согласен с тем, что foreach информативнее или понятнее inject-а, поскольку здесь сказываются привычки и устоявшиеся стереотипы. Скорее так: для Smalltalk программиста inject -- это более информативный аналог foreach-а для C#-программиста. И наоборот: для C#-программиста inject -- это извращенно закамуфлированный foreach.

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

C>А вообще, идея с бинарным репозиторием исходных файлов, с которым IDE работает напрямую, была опробована в VisualAge for Java. Успешно провалилась

Как в VisualAge все было устроено не знаю, а вот Store в VisualWorks использует в качестве репозитория реляционную базу и единницей хранения является метод. И все замечательно работает. Лично принимал участие в проекте, который этим пользуется (проект на сейчас жив, и даже очень жив).

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

VD>Тогда тебе нужен именно текстовый дифер без каких бы то ни было извратов.

ну да. просматривать всю историю изменений и сравнивать?

Д>>Я не очень то много работал с Явой, а VisualAge и вовсе ни разу не видел А что с ней было не так?

VD>VisualAge — это вообще вещь в себе. Ни как не забуду как в 95 году, когда у народа было по 4-8 метров на машинах эти орлы вывалили VisualAge фор что попало который даже для С++ требовал минимум 64 метра памяти.

Ну, быстродействие их реализации — это уже отдельный вопрос.

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

C>Это и есть суть команды blame (удачное имя ) — она показывает в какой
C>ревизии (и кем) изменялась данная строчка. А вообще, с нормальной SCM
C>проблем посмотреть историю изменений обычно не возникает.

строчки, которая меня интересует, в текущей версии просто нет. В какой ревизии файла она была, я не знаю.
starteam — это видимо не нормальная система?

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

VD>А какая разница для дифира бинарный формат или плоский текст? Он один хрен будет сравнивать версию с версией.

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

Дарней wrote:

> C>Это и есть суть команды blame (удачное имя ) — она показывает в какой
> C>ревизии (и кем) изменялась данная строчка. А вообще, с нормальной SCM
> C>проблем посмотреть историю изменений обычно не возникает.
> строчки, которая меня интересует, в текущей версии просто нет.

Есть blame'ы, показывающие удаленные строчки. В частности, в IDEA как
раз такой встроен, еще есть скриптик для svn.

> В какой ревизии файла она была, я не знаю. starteam — это видимо не
> нормальная система?

Наверное.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Дарней wrote:

> VD>Тогда тебе нужен именно текстовый дифер без каких бы то ни было
> извратов.
> ну да. просматривать всю историю изменений и сравнивать?

Зачем _всю_ историю? Выделяем нужный кусок и берем историю для него.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

E>Скорее так: для Smalltalk программиста inject -- это более информативный аналог foreach-а для C#-программиста. И наоборот: для C#-программиста inject -- это извращенно закамуфлированный foreach.

Заметка: в Smalltalk, естественно, есть аналог foreach (даже for ), но ими пользуются только в особо извращенных ситуациях, потому как inject, при наличии привычки, чище выражает накопление результата прохода по коллекции.

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

B>Приведенный код показывает, что просто получение суммы двух чисел — паттерн очень бесполезный и используется в основном в алгоритмах, для создания полезных

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

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

VD>Вообще-то речь шал не об этом.
Отчего-же. С extention мы вообще можем отказаться не только от инициализации переменных(что есть у тебя) но и вообще от описания цикла.
Что-то типа этого:

var sum=array.Sum(x => x>5);

Можем добавить например агрегирующую функцию с указанием индексов
public static int Sum<T>(this IEnumerable<T> source, int begin, int end)
Тогда сможем вызывать не менее продвинуто:

//получить сумму от 1 по 10
var sum=array.Sum(1, 10);

Или ввести свой более гибкий агрегат

public static T MyAggregate<T,K>(this IEnumerable<T> source, K initValue, Func<T, K> aggregate)
{
K aggr=initValue;
foreach(T elem in source)
    aggr=aggregate(aggr, elem);
return aggr;
}
//использование - получение суммы
var sum=array.MyAggregate(0, (agg,x) =>(agg+x));

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

С уважением, Gleb.

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

C>Зачем _всю_ историю? Выделяем нужный кусок и берем историю для него.

Нужный кусок чего? Файла? В первый раз слышу, что такое возможно
В любом случае. Нужного мне куска в текущей ревизии файла НЕТ

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

C>Есть blame'ы, показывающие удаленные строчки. В частности, в IDEA как
C>раз такой встроен, еще есть скриптик для svn.

Все удаленные строчки за всю историю данного файла? Нет уж, не надо мне такой радости

>> В какой ревизии файла она была, я не знаю. starteam — это видимо не
>> нормальная система?

C>Наверное.

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

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

Как обычно — реактивность мышления не является объективным фактором. Поэтому скипаем.

VD>ЗЫ

VD>А вот так это будет выглядеть на C# 3.0:
VD>

VD>int[] array = { 1, 2, 3, 4, 5, 6  };

VD>var sum = array.Sum();
VD>

VD>Понятнее некуда.

Минус полиморфизм для Sum.

VD>Или "вариации на тему":
VD>

VD>var sum = array.Fold((fold, second) => fold + second);
VD>

А что выдаст для одного элемента или пустого списка?

VD>Ну, и самое простое... C# 1.0:
VD>

VD>int sum = 0;

VD>foreach (int elem in array)
VD>    sum += elem;
VD>

Это эквивалент не для #inject:into: а для вот этого

sum := 0.
array do: [:elem | sum := sum + elem].

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

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

VD>>Вообще-то речь шал не об этом.
GZ>Отчего-же. С extention мы вообще можем отказаться не только от инициализации переменных(что есть у тебя) но и вообще от описания цикла.
GZ>Что-то типа этого:
GZ>

GZ>var sum=array.Sum(x => x>5);
GZ>

GZ>Можем добавить например агрегирующую функцию с указанием индексов
GZ>public static int Sum<T>(this IEnumerable<T> source, int begin, int end)
GZ>Тогда сможем вызывать не менее продвинуто:
GZ>

GZ>//получить сумму от 1 по 10
GZ>var sum=array.Sum(1, 10);
GZ>

GZ>Или ввести свой более гибкий агрегат
GZ>

GZ>public static T MyAggregate<T,K>(this IEnumerable<T> source, K initValue, Func<T, K> aggregate)
GZ>{
GZ>K aggr=initValue;
GZ>foreach(T elem in source)
GZ>    aggr=aggregate(aggr, elem);
GZ>return aggr;
GZ>}
GZ>//использование - получение суммы
GZ>var sum=array.MyAggregate(0, (agg,x) =>(agg+x));
GZ>

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

GZ>С уважением, Gleb.

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

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

Oops. Только сейчас заметил ветку с аналогичным сообщением от Влада.
_>В плюс идет то, что это действительно близко повторяет то, что есть в Smalltalk.
_>В большой минус — это жуткое нагромождение, нет полиморфизма (хотя в коллекциях он практически не нужен для сложных операций),
Нет. Он сам по себе и есть полиморфизм.

_>и по скобкам в сложных выражениях приближается к тому же глубоко охаенному Лиспу.
Нет, не приближается. Это все-таки C#. Есть лямбда выражения, есть лямбда statement.
То есть вполне можно описать эквивалентные выражения

(x, y)=>(x+y) 
(x, y)=>{return x+y;}//в этом случае - это нормальная программа на С# без всяких причуд

С уважением, Gleb.

Дарней wrote:

> C>Зачем _всю_ историю? Выделяем нужный кусок и берем историю для него.
> Нужный кусок чего? Файла? В первый раз слышу, что такое возможно

В IDEA есть Кроме того, для svn есть такой же скриптик.

> В любом случае. Нужного мне куска в текущей ревизии файла НЕТ

Выделяем кусок, где он ДОЛЖЕН быть, а потом смотрим его историю.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Дарней wrote:

> C>Есть blame'ы, показывающие удаленные строчки. В частности, в IDEA как
> C>раз такой встроен, еще есть скриптик для svn.
> Все удаленные строчки за всю историю данного файла? Нет уж, не надо
> мне такой радости

Нет, скрипт просто выполняет blame, смотрит в какой ревизии изменились
нужные строчки, берет эти ревизии, делает diff, а потом снова blame уже
дальше в истории.

>>> В какой ревизии файла она была, я не знаю. starteam — это видимо не
>>> нормальная система?
> C>Наверное.

Лучшая SCM, которую я видел, — это Perforce. Из свободных — Subversion.
Сейчас использую связку Subversion+svk.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

GZ>Oops. Только сейчас заметил ветку с аналогичным сообщением от Влада.
_>>В плюс идет то, что это действительно близко повторяет то, что есть в Smalltalk.
_>>В большой минус — это жуткое нагромождение, нет полиморфизма (хотя в коллекциях он практически не нужен для сложных операций),
GZ>Нет. Он сам по себе и есть полиморфизм.

Он полиморфизм в той лишь степени, насколько он использует полиморфные методы. А этот метод сам по себе — статический алгоритм по полиморфному интерфейсу.
То, что не хватает MyAggregate<T,K> — это множественная диспетчеризация для отдельных случаев, когда foreach использовать нельзя/нежелательно, а нужен какой-либо другой способ обхода коллекции.

_>>и по скобкам в сложных выражениях приближается к тому же глубоко охаенному Лиспу.
GZ>Нет, не приближается. Это все-таки C#. Есть лямбда выражения, есть лямбда statement.
GZ>То есть вполне можно описать эквивалентные выражения
GZ>

GZ>(x, y)=>(x+y) 
GZ>(x, y)=>{return x+y;}//в этом случае - это нормальная программа на С# без всяких причуд
GZ>

Меня запись array.MyAggregate(0, (agg,x) =>(agg+x)) впечатлила.
Синтаксический оверхед однако.

GZ>С уважением, Gleb.

То что меня смущает в этих нововведениях несмотря на плюсы — отсутствие единообразия и единой концепции с остальным языком. Как следствие возникает множество ограничений и частных случаев.
C# 2.0 был обычным жава-подобным языком, а теперь произошел скачек на тропинку C++. За что боролись...
Пожалуй самым кошмарным занятием будет написание тулзов для C# language. Это будет путь не одиночек, а больших корпораций. Не завидую участи R#...

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

C>Дарней wrote:

>> C>Зачем _всю_ историю? Выделяем нужный кусок и берем историю для него.
>> Нужный кусок чего? Файла? В первый раз слышу, что такое возможно

C>В IDEA есть Кроме того, для svn есть такой же скриптик.

Жаль, что я пишу не на Яве

>> В любом случае. Нужного мне куска в текущей ревизии файла НЕТ

C>Выделяем кусок, где он ДОЛЖЕН быть, а потом смотрим его историю.

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

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

_>Он полиморфизм в той лишь степени, насколько он использует полиморфные методы. А этот метод сам по себе — статический алгоритм по полиморфному интерфейсу.
Ага. Практически правильно. Если ты хочешь использовать полиморфизм, пиши в объект. Это кстати и рекомендуется в спецификации. Но и в данном случае можно сделать много интересного.
Ну например, у тебя есть бизнес объект

public class BO
{
public int ID;
public int BOField;
};

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

namespace BD
{
public static class BOExtention
{
   public static ToDB(this BO source)
   {
       GetDBManager().Update="update into table(Field) values(@field) where id=@id";
       .........
   }
}
}

Во все программе этот метод не нужен и я бы сказал вреден. А вот в классе где нужен, добавляем просто через using namespace от данного класса, и вуаля. Метод есть. Если нужен другое поведение, то оперируем именем namespace. Например, в каком то классе тебе нужно представить этот объект в XML. Можно варьировать бизнес-логику типа в зависимости от местонахождения.

_>Меня запись array.MyAggregate(0, (agg,x) =>(agg+x)) впечатлила.
_>Синтаксический оверхед однако.
Можно записать и так

array.MyAggregate(0, (agg,x) =>agg+x)

Можно и так

array.MyAggregate(0, (agg,x) =>{return GetSum(agg, x);})

а можно и совсем круто

array.MyAggregate(0, new delegate(int agg, int x){return agg+x;});

Собственно лямбда здесь не больше чем синтаксический сахар для последнего варианта. Поэтому аверхеда здесь мало.

_>То что меня смущает в этих нововведениях несмотря на плюсы — отсутствие единообразия и единой концепции с остальным языком. Как следствие возникает множество ограничений и частных случаев.
Пока это все мечты. До воплощения в реальность еще ох как долго. И возможно многие ограничения снимутся. А насчет единообразия, быстро привыкаешь к этим приблудам. Пару дней посидел как-то, и теперь мучаюсь. Нехватает.

С уважением, Gleb.