@Admin вижу вы тут сделали отдельный .Print(ln) для строк. Как насчёт тогда в .Print(ln) для последовательностей убрать проверку на char. Сейчас так:
/// Выводит последовательность на экран, используя пробел в качестве разделителя
function Print<T>(Self: sequence of T): sequence of T; extensionmethod;
begin
if typeof(T) = typeof(char) then
Result := Self.Print('')
else
Result := Self.Print(PrintDelimDefault);
end;
/// Выводит последовательность на экран, используя пробел качестве разделителя, и переходит на новую строку
function Println<T>(Self: sequence of T): sequence of T; extensionmethod;
begin
if typeof(T) = typeof(char) then
Result := Self.Println('')
else
Result := Self.Println(PrintDelimDefault);
end;
То есть такой код:
begin
var s := '123';
s.Println;
s.AsEnumerable.Println;
end.
Выведет 2 одинаковые строчки. А если убрать ту проверку:
/// Выводит последовательность на экран, используя пробел в качестве разделителя
function Print<T>(Self: sequence of T): sequence of T; extensionmethod;
begin
Result := Self.Print(PrintDelimDefault);//так можно ещё и сделать PrintDelimDefault значением поумолчанию
end;
/// Выводит последовательность на экран, используя пробел качестве разделителя, и переходит на новую строку
function Println<T>(Self: sequence of T): sequence of T; extensionmethod;
begin
Result := Self.Println(PrintDelimDefault);
end;
То вывод будет такой:
123
1 2 3
Что более логично, если выводится последовательность - её всегда разделяет пробелами, но не когда элементы имеют тип char. На сколько я понимаю - это как раз было сделано чтоб строки правильно выводились, пока небыло отдельного .Print(ln) для них.
@Admin, как Вы смотрите на запрет объявлять абстрактные и виртуальные методы с модификатором private:
type
T = class
private
procedure P(); abstract;
end;
begin
end.
? Я не знаю как в других Паскалях - кто знает - пусть отпишется здесь. Но с точки зрения логики эта возможность бессмысленна, поскольку такие методы не будут видны в классах-потомках и толку от возможности их переопределения ноль. Если обратиться к C#:
using System;
namespace CSrharpApplicationTest
{
public class Program
{
private abstract void P();
public static void Main(string[] args) => P(() => Console.WriteLine());
}
}
, то этот код выдаст:
“Program.P()”: виртуальные и абстрактные члены не могут быть закрытыми.
Перед тем, как создавать тему, неплохо посмотреть все остальные - может быть, Ваше предложение или его какие-то части уже рассматривались? Но даже если и нет - тема уже есть для предложений и замечаний.
Хорошо бы было привести примеры IDE, в которых это реализовано. В Lazarus и Visual Studio такого я не нашёл. Поищите, пожалуйста, IDE, в которых такая возможность реализована.
То, что фича не первой необходимости можно видеть по её отсутствию в популярных IDE. Можно, конечно, возразить, что целых 2 лишние строчки добавляют регионы. Но, с другой стороны, это плата за гибкость регионов (которые можно ставить как хочешь и где хочешь), чтобы не позволяла делать предложенная фича - она бы была жёстко привязана к interface/implementation/initialization/finalization. Вообще, регионов не должно быть слишком много в коде, как говорил мой знакомый.
Разработчики запрещают кучу Issue по улучшению IDE, предлагая взамен использовать Pull Requests. Можно посмотреть на это как с отрицательной, так и с положительной стороны. Я посмотрю со второй - думаю, они подталкивают нас развиваться.
Полагаю, все в разы прозаичнее. Вряд ли хватает рук реализовывать даже задачи первой необходимости (вроде багов с лямбдами, о которых раз за разом рассказывает @Admin), а уж на всякие дополнения вроде сворачиваемых интерфейсов с имплементейшенами точно времени нет. Пул-реквесты - общепринятый способ контрибутить в проекты с целью их развития. Суть: “У тебя много свободного времени? Сядь и напиши. А мы посмотрим, оценим, порефакторим с целью приведения сего добра к принятому виду, и примем в продакшен.”. Так работают все open-source проекты, и этот - не исключение.
В ближайшее время выйдет модифицированный модуль GraphWPF с более мягкой графикой при большом количестве примитивов (без скачков и замедлений)
Одно из основных направлений работы - устранение значительного количества багов в лямбдах, выявленных нашими замечательными тестировщиками. Там их накопилось вместе с улучшениями достаточно много - вагон и маленькая тележка.
Создание платформы для разработки 2D-игр. Это нам нужно для обучения наших школьников.
Из запланированных языковых изменений - доработка pattern matching - в частности для сопоставления с константами и кортежами, срезы матриц, срезы массивов и строк на запись, новые средства автоклассов, распространение конструкции match на выражения (switch expressions в C# 8.0).
Из “незаметных” языковых изменений - ускорение работы со встроенными множствами и, возможно, замена их реализации на HashSet.
По поводу того, что в C# 8.0. Мы внимательно присматриваемся к возможности создания traiats (интерфейсов с частичной реализацией). Но пока не думаем про их реализацию. Надо посмотреть примеры их использования в будущем C# и как они будут там реализованы.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021