Замечания и предложения

Не должна. И вызвать по идее можно всё

С той проблемой я уже разобрался, на самом деле нужно было использовать PABCRtl, а я костыли городил

Почему есть Println для array[,] of T

/// Вывод двумерного массива, w - ширина поля вывода
function Print<T>(Self: array [,] of T; w: integer := 4): array [,] of T; extensionmethod;
begin
  for var i := 0 to Self.RowCount - 1 do
  begin
    for var j := 0 to Self.ColCount - 1 do
    begin
      if PrintMatrixWithFormat then
        Write(StructuredObjectToString(Self[i, j]).PadLeft(w))
      else Print(Self[i, j]);
    end;
    Writeln;  
  end;
  Result := Self;  
end;

но нет для array of T?

Из-за этого в коде:

begin
  var arr := ArrRandom(10).Println;
  var matr := MatrRandom(10).Println;
end.

arr будет иметь тип sequence of integer. Хотя, можно написать так:

type
  &array<T> = array of T;

begin
  var arr := &array&<integer>(ArrRandom(10).Println);
  var matr := MatrRandom(10).Println;
end.

Но это уже не так красиво, согласитесь

1 лайк

Подозреваю, разработчики думали, что он есть… Но забыли в коде дописать .ToArray.

Для последовательностей это Println - он определён над последовательностями. Нечего последовательность неявно переводить назад в массив - теряется ленивость.

А двумерные массивы - не последовательности.

1 лайк

Вообще лучше написать такой .Println:

function Println<T>(self: T): T; extensionmethod;
where T: System.Collections.IEnumerable;
begin
  foreach var el in self do Print(el);
  Result := self;
end;

begin
  var coll: ICollection<byte>;
  var coll2 := coll.Println; // компилятор понимает что у coll2 тип не IEnumerable<byte>, а именно ICollection<byte>, потому что шаблоны
end.

Это сразу работает для всех последовательностей, а при вызове для типов наследующих от последовательности - возвращает исходный тип, а не IEnumerable. И для массивов это тоже будет работать, то есть можно сразу несколько старых Println, Print и PrintLines-ов заменить подобными.

Какая ленивость? В реализации вашего Println она отсутствует.

2 лайка

Println для последовательности - только ленивый. Иного и быть не может

1 лайк

Ленивый это так:

function LazyPrintln<T>(self: sequence of T): sequence of T; extensionmethod;
begin
  foreach var el in self do
  begin
    Print(el);
    yield el;
  end;
end;

А то что у вас (Result := self) - это не в стили ленивости. Это только в стиле ООП.

1 лайк

Кроме того. Весь смысл этого Result := self в ООП стиле - в том чтоб писать программы в 1 строчку (применяя несколько функций к 1 объекту). Тем временем каждая 3-5 программа на куберфоруме содержит что то такое:

begin
  var a := ArrRandom;
  a.Println;
end.

То есть приходиться разбивать на 2 строчки, потому что криво реализован ООП стиль.
Иначе у a будет тип последовательности вместо массива, а у массивов всё же есть незаменимый функционал (как доступ к последнему элементу, без вычисления всей последовательности).

1 лайк

Println должен возвращать последовательность. Всё остальное - да - криво

1 лайк

И при выводе массивов? Почему? Снова принципиальность ради принципиальности?

1 лайк

Возможно он действительно должен. Должен каким-то высоким обстоятельствам. Но для пользователя еще бы хотелось, чтобы он был должен и житейскому смыслу. Согласно которому Print - это создание “твердой копии”. Т.е. визуализация копии внутреннего представления. И посему обычная логика немножко привстает на дыбы ,когда оказывается, что копирование меняет тип оригинала. Причем не всегда, что усложняет запоминание.

Это были аргументы “pro”. А теперь “contra”.

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

В общем, мое предложение простое: flame mode off и все остается, как есть.

2 лайка

В отличии от массивов, для распаковки списка, стека, очереди или хэшсета синоним создавать не нужно

1 лайк

Может быть, в настройках имеет смысл добавить “птичку”, взведя которую получим автоматическую проверку наличия обновлений версии? Т.е. чтобы после загрузки IDE у желающего автоматом выполнялся пункт меню “Помощь” - “Проверить обновления”. Ленивым и забывчивым будет напоминать, что можно обновиться.

Разработчики так и не смогли сделать асинхронную проверку обновлений. А без этого - вся IDE зависает пока проверяются обновления.
Кроме того, обновления лучше проверять при закрытии IDE.

Что есть - то и есть. Я предлагаю всего лишь ввести опциональную возможность автоматически после загрузки среды вызывать пункт меню. Ничего особого делать для этого не нужно.

Только IDE тогда будет всегда зависать при отсутствии подключения к интернету.

Если это опционально, пользователь сам решит, нужна ему такая возможность или нет. Есть пользователи, имеющие стабильный интернет, раздаваемый по сети 24/7. Например, я ))

А если вам отключат интернет вы даже в настройки зайти из-за зависания не сможете ))

Придётся .ini-файл редактировать

Если отключат - подожду. ибо что делать-то в РАВС без интернет?

А сейчас что - удобно? Вон человек вопрос написал, я зашел, проверил, считал что версия последняя, смотрел совсем недавно. Кто знал, что вышло обновление? Практически при каждом входе надо запускать проверку руками. Иногда забываешь, поскольку никакой закономерности в частоте появления обновлений нет и информации о том, что обновление было, нет также.

И откатить обновление назад нельзя, если в нем что-то возникло, надо сидеть и ждать исправлений (конечно, если важно именно то, что сломалось). Это потому, что нет предыдущей версии нигде.