Версия PascalABC.NET 3.5

Хорошо, тогда как насчёт этого:

  • Если в конце строчке стоит арифметический оператор или не все скобки закрыты - ; ставить не надо.

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

Есть ещё что то что я упускаю?

Не все скобки закрыты - это глубокий разбор. В частности, выражение может быть на нескольких строчках.

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

Например,

procedure
A
;
begin <Enter>

не увидит процедуру и добавит

end.

а не

end;

Оказывается, что в PascalABC.NET имеются рабочие частичные классы:

type
  T = partial class
    public a: integer := 1;
  end;
  
  T = partial class
    public b: integer := 2;
  end;

begin
  var a := new T;
  write(a.a + a.b);
end.
1 лайк

Хакер…

begin
  var a: array of byte;
  a := new byte[32];
end.

Превращается в

begin
  var a: array of byte;
  a := new;byte[32];
  
end.

Это уже исправлено. Закачал на сайт

Проверка обновлений не показывает что вышла новая версия…

Проверьте снова

Я тогда ещё перескачал всё равно, забыл сказать, и ошибка всё ещё была.

А вот теперь да, проверка обновления сработала, в новой версии не воспроизводится.

А за это особое спасибо…

Неформатированный вид - хорошая вещь. @Admin, верно ли я понимаю, что он работает только для типов NET? Спрашиваю поскольку в ниже приведённом коде DebuggerTypeProxy не действует.

uses NETMouseForPascal;
uses System.Diagnostics;

type
  ProxyTypeT = class;
  
  [DebuggerTypeProxyAttribute('Test.ProxyTypeT')]
  SomeT = class
    public auto property Shown: integer := 1;
    public auto property Hidden: integer := 2;
  end;
  
  ProxyTypeT = class
    [DebuggerBrowsableAttribute(DebuggerBrowsableState.Never)]
    {private} instance: SomeT; // The compiler error is occured if I uncomment this access modifier.
    
    public constructor(instance: SomeT) := self.instance := instance;
    
    [DebuggerBrowsableAttribute(DebuggerBrowsableState.RootHidden)]
    {public} property Shown: integer read instance.Shown; // The compiler error is occured if I uncomment this access modifier.
  end;

begin
  var x := new SomeT();
  x.AutoPrintLine();
end.

Атрибут надо ставить после модификатора доступа. Это конечно не хорошо…

Кому не хорошо, а кому правильно. Атрибут относится к сущности, а не к блоку сущностей с модификатором доступа.

1 лайк

Модификаторы доступа вынес отдельно:

uses NETMouseForPascal;
uses System.Diagnostics;

type
  ProxyTypeT<T> = class;
  
  [DebuggerTypeProxyAttribute('Test.ProxyTypeT`1')]
  SomeT<T> = class
  public
    auto property Shown: integer := 1;
    auto property Hidden: integer := 2;
  end;
  
  ProxyTypeT<T> = class
  private
    [DebuggerBrowsableAttribute(DebuggerBrowsableState.Never)]
    instance: SomeT<T>;
    
  public
    constructor(instance: SomeT<T>) := self.instance := instance;
    
    [DebuggerBrowsableAttribute(DebuggerBrowsableState.RootHidden)]
    property Shown: integer read instance.Shown;
  end;

begin
  var x := new SomeT<byte>();
  x.AutoPrintLine();
end.

Возможно, так даже красивее.

Вот только объявлять 1 блок на несколько сущностей - прошлый век. Конечно, вы это поддерживаете, но никто не мешает применять атрибут к первой сущности блока, если в блоке их несколько.

Причин отказа модификации языка в этом аспекте может быть несколько: технические трудности, обратная совместимость и т.д. Полагаю, что в данном случае одна из двух.

P.S. Кому хочется посмотреть, держите: интересная статья про атрибуты в Delphi.

1 лайк

@Admin, посмотрите, пожалуйста, и примите/отклоните пулл https://github.com/pascalabcnet/pascalabcnet/pull/2116

Вы часто обновляете GraphWPF, так что если сейчас не разобраться, то позже возникнет конфликт

Написал почему не приму

Хорошо, завтра уберу var-параметры

Я полагаю, что главной причиной отказа принятия pull-request была следующая мысль: Если мы (разработчики) принимаем pull-request с расширением функционала стандартного модуля один раз, то почему не можем сделать это второй и третий?..

Точнее, модуль может разрастить в какой-то степени и времени на его обучение потребуется больше. Что означает, что он потеряет свою “легковесность”, которая важна при обучении, поскольку начинающих перегружать материалом - не лучшее решение, а также потому что подобные “легковесные” модули позволяют быстро заложить принципы построения программ (пусть, даже и приблизительные), что поспособствует переходу на серьезные технологии.

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

Вообще, OnClose нужен на проверку “сохранять ли изменённые данные” и обязан иметь возможность отмены закрытия. Но это больше относится к GraphWPF/WPFObjects, а для Graph3D оно уже не так важно.

2 лайка