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


#1147

@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) для них.


#1148

@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()”: виртуальные и абстрактные члены не могут быть закрытыми.


#1149

Хорошо. Пишите Issue


#1150

Я последовательность символов всегда воспринимаю как строку. Я бы оставил как есть.


#1151

Здравствуйте,здесь можно кидать предложения: чего не хватает в паскале?

На данный момент у меня возникла неудобность в паскале:

  • когда пишешь модуль, нельзя сворачивать interface, initialization и finalization. хотелось что бы исправили это.

пока еще не возникли проблемы , так что кидайте сюда какие у вас неудобства на паскале.Также я буду дополнять список.


#1152

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


#1153
- Анна-Ванна, наш отряд
Хочет видеть поросят!
Рыльца - пятачками?
Хвостики - крючками?

#1154

:rofl: :rofl:

Забавляет название самой темы.


#1155

Хорошо бы было привести примеры IDE, в которых это реализовано. В Lazarus и Visual Studio такого я не нашёл. Поищите, пожалуйста, IDE, в которых такая возможность реализована.


#1156

Да все это “Страдания юного Вертера”.

{$region xxx}
...
{$endregion}

И все проблемы…


#1157

То, что фича не первой необходимости можно видеть по её отсутствию в популярных IDE. Можно, конечно, возразить, что целых 2 лишние строчки добавляют регионы. Но, с другой стороны, это плата за гибкость регионов (которые можно ставить как хочешь и где хочешь), чтобы не позволяла делать предложенная фича - она бы была жёстко привязана к interface/implementation/initialization/finalization. Вообще, регионов не должно быть слишком много в коде, как говорил мой знакомый.

Разработчики запрещают кучу Issue по улучшению IDE, предлагая взамен использовать Pull Requests. Можно посмотреть на это как с отрицательной, так и с положительной стороны. Я посмотрю со второй - думаю, они подталкивают нас развиваться.


#1158

Тогда должны быть развитые namespace


#1159

Полагаю, все в разы прозаичнее. Вряд ли хватает рук реализовывать даже задачи первой необходимости (вроде багов с лямбдами, о которых раз за разом рассказывает @Admin), а уж на всякие дополнения вроде сворачиваемых интерфейсов с имплементейшенами точно времени нет. Пул-реквесты - общепринятый способ контрибутить в проекты с целью их развития. Суть: “У тебя много свободного времени? Сядь и напиши. А мы посмотрим, оценим, порефакторим с целью приведения сего добра к принятому виду, и примем в продакшен.”. Так работают все open-source проекты, и этот - не исключение.


#1160

@Admin, в C# 8.0 планируется добавить расширение всего и вся.

Планируется ли у Вас подобное, или нет? Это, сейчас, разумеется, не особо нужно, просто интересны Ваши планы на развитие PascalABC.NET.


#1161

Кошмар какой-то. Интерфейсы с реализацией. Скоро множественное наследование введут. И испоганят язык окончательно.