Возможно как нибудь список статей получить на rss ленту? А то на сайте очень сложно следить за тем, что уже прочитал и что ещё можно было бы, тем более обещаете пополнение.
>> Extension methods - очень мощное оружие, но и очень опасное. Почти как указатели. Применять необходимо с очень большой опаской и все методы должны быть снабжены комментариями - иначе при review такого кода получите очень много вопросов.
С чего вы так решили? Существует язык компонентный паскаль (Оберон 2), его создатель Вирт, во многих статьях писал, что текущая реализация ООП (в языка C++, Delphi, C#) является не очень удачной (его гложили отличия класса от типа) и в своём языке реализовал ООП основываясь только на записях (обычные типы), к которым можно прицеплять методы, как раз с помощью подобия extension methods.
Процедуры, описанные глобально , могут быть связаны с каким-либо типом записей, описанным в том же модуле. Такие процедуры называют методами [methods], связанными с данным типом записей. Связь выражается посредством указания типа принимающего параметра в заголовке описания процедуры. Получающий параметр может быть VAR или IN параметром типа T или параметром-значением типа POINTER TO T, где T — тип записей. Метод связан с типом T и считается в нем локальным.
Если метод M связан с типом T0, он также неявно связан с любым потомком T1 типа T0. Однако если метод M' (с тем же именем, что и у M) описан как связанный с T1, он становится связан с T1 вместо M. M' считается переопределением M для T1. Списки формальных параметров M и M' должны соответствовать [match], кроме случаев, когда M — процедура-функция, возвращающая указательный тип. В последнем случае тип результата функции M' должен быть расширением типа результата M (ковариантность) (см. Приложение A). Если M и T1 экспортируются (см. гл. 4), то M' тоже должен экспортироваться.
----------------------
При этом злые языки говорят, что мелкомягкие сотрудничают с Виртом и перетаскивают интересные вещи себе в C#. При этом любовь к перетаскиванию уже явна была неоднократна (с тем же LINQ), поэтому неверить как-то не получается.
И ещё пример: Оберон был первым компилируемым языком с поддержкой автоматической чистки мусора (возможно, тоже наследие Оберона).
Очень заинтересовала статья. Прям не вериться, что функциональный язык может на сколько упростить жизнь. Раньше читал чуть-чуть про хаскел и тому подобные языки, но все время никак не мог представить как именно он подойдет к моей работе. В основном все примеры сводятся либо к математическим функциям (которые за меня выполняет БД), либо к формированию строк (тут не поспоришь, любой программист часто использует такие циклы), но моя работа не состоит в основном из формировании строк (такие простые циклы используются один на 1000 строк кода), поэтому их оптимизация на сколько я понимаю будет только для души. При этом существуют другие более сложные и запутанные места, вот, например, реализация сериализации объектов в файловый поток
if (item.isList) {
if (item.list) {
resultBlob->WriteChar(1); // Имеются сведения о списке
// Используется косвенная рекурсия
WriteParamsListToBlob(item.list, resultBlob);
} else {
resultBlob->WriteChar(0); // Нет сведений
}
} else {
if (item.value) {
resultBlob->WriteChar(1); // Имеются сведения о значении
item.value.SaveToBlob(resultBlob);
} else {
resultBlob->WriteChar(0); // Нет сведений о значении
}
}
}
void WriteParamsListToBlob(ParamsListBase list, /*out*/ CBlob *resultBlob)
{
resultBlob->WriteInt(2); // Версия
resultBlob->WriteString("ParamsList");
resultBlob->WriteInt(list.Count()); // Количество
ParamItem item = list.GetFirst();
while (item) {
resultBlob->WriteChar(1); // Отмечаем, что есть ещё записи.
WriteParamItemToBlob(item, resultBlob);
item = list.GetNext();
}
resultBlob->WriteChar(0); // Отмечаем, что больше записей нет.
}
Задача такая: существует коллекция элементов, которая может содержать элементы и такие же коллекции (рекурсивная структура, на сколько я знаю для ФЯ это наиболее удобная форма хранения данных). Требуется сериализовать коллекцию в файловых поток (resultBlob это stream, который потом записывается в файл). Возможно ли такие не очень простые функции преобразовать в более понятный вид. Особенно хотелось обратить внимание на формат потока, так как взаимодействие осуществляется с другой частью системы, которую пишут другие люди, поэтому протоколы взаимодействия четко описанны и так же четко должны поддерживаться.
С чего вы так решили? Существует язык компонентный паскаль (Оберон 2), его создатель Вирт, во многих статьях писал, что текущая реализация ООП (в языка C++, Delphi, C#) является не очень удачной (его гложили отличия класса от типа) и в своём языке реализовал ООП основываясь только на записях (обычные типы), к которым можно прицеплять методы, как раз с помощью подобия extension methods.
http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm
Процедуры, описанные глобально , могут быть связаны с каким-либо типом записей, описанным в том же модуле. Такие процедуры называют методами [methods], связанными с данным типом записей. Связь выражается посредством указания типа принимающего параметра в заголовке описания процедуры. Получающий параметр может быть VAR или IN параметром типа T или параметром-значением типа POINTER TO T, где T — тип записей. Метод связан с типом T и считается в нем локальным.
ProcedureHeading = PROCEDURE [Receiver] IdentDef [FormalParameters] MethAttributes.
Receiver = "(" [VAR | IN] ident ":" ident ")".
MethAttributes = ["," NEW] ["," (ABSTRACT | EMPTY | EXTENSIBLE)].
Если метод M связан с типом T0, он также неявно связан с любым потомком T1 типа T0. Однако если метод M' (с тем же именем, что и у M) описан как связанный с T1, он становится связан с T1 вместо M. M' считается переопределением M для T1. Списки формальных параметров M и M' должны соответствовать [match], кроме случаев, когда M — процедура-функция, возвращающая указательный тип. В последнем случае тип результата функции M' должен быть расширением типа результата M (ковариантность) (см. Приложение A). Если M и T1 экспортируются (см. гл. 4), то M' тоже должен экспортироваться.
----------------------
При этом злые языки говорят, что мелкомягкие сотрудничают с Виртом и перетаскивают интересные вещи себе в C#. При этом любовь к перетаскиванию уже явна была неоднократна (с тем же LINQ), поэтому неверить как-то не получается.
И ещё пример: Оберон был первым компилируемым языком с поддержкой автоматической чистки мусора (возможно, тоже наследие Оберона).
void WriteParamItemToBlob(ParamItem item, /*out*/ CBlob *resultBlob)
{
resultBlob->WriteInt(1); // Версия
resultBlob->WriteString(item.name);
resultBlob->WriteChar(item.isList);
if (item.isList) {
if (item.list) {
resultBlob->WriteChar(1); // Имеются сведения о списке
// Используется косвенная рекурсия
WriteParamsListToBlob(item.list, resultBlob);
} else {
resultBlob->WriteChar(0); // Нет сведений
}
} else {
if (item.value) {
resultBlob->WriteChar(1); // Имеются сведения о значении
item.value.SaveToBlob(resultBlob);
} else {
resultBlob->WriteChar(0); // Нет сведений о значении
}
}
}
void WriteParamsListToBlob(ParamsListBase list, /*out*/ CBlob *resultBlob)
{
resultBlob->WriteInt(2); // Версия
resultBlob->WriteString("ParamsList");
resultBlob->WriteInt(list.Count()); // Количество
ParamItem item = list.GetFirst();
while (item) {
resultBlob->WriteChar(1); // Отмечаем, что есть ещё записи.
WriteParamItemToBlob(item, resultBlob);
item = list.GetNext();
}
resultBlob->WriteChar(0); // Отмечаем, что больше записей нет.
}
Задача такая: существует коллекция элементов, которая может содержать элементы и такие же коллекции (рекурсивная структура, на сколько я знаю для ФЯ это наиболее удобная форма хранения данных). Требуется сериализовать коллекцию в файловых поток (resultBlob это stream, который потом записывается в файл). Возможно ли такие не очень простые функции преобразовать в более понятный вид. Особенно хотелось обратить внимание на формат потока, так как взаимодействие осуществляется с другой частью системы, которую пишут другие люди, поэтому протоколы взаимодействия четко описанны и так же четко должны поддерживаться.