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

PABCRtl.dll очень-очень крутая штука!

А можете сделать так, чтобы инициализация модулей находилась в статическом конструкторе класса модуля (к примеру, в модуле PABCSystem в типе PABCSystem.PABCSystem будет статический конструктор, вызывающий __ InitModule__)? Самому PascalABC.NET я не знаю как поможет это, но вот использовать модули паскаля на других .NET языках станет невероятно удобно!

1 лайк
  1. Как когда-то сказал @Admin, модули PascalABC.NET - не рассчитаны на использование вне данного языка. И я поддерживаю данную точку зрения, поскольку при использовании вне PascalABC.NETC#, например), на глаза попадаются детали реализации модулей (которые для начинающих не очевидны, и нигде не описаны).

  2. Вспоминая о том, что PascalABC.NET - учебный язык, удобнее всего использовать учебные модули, заточенные под него, на нём же, ибо, повторюсь, в PascalABC.NET это делается максимально просто, без нужды объявлять класс и метод Main, а для новичков лишние “заморочки” - не нужны.

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

Как это относится к данной теме? Решили объем сообщения водой увеличить?

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

В третьих, перестаньте тыкать. Мы с Вами не друзья, просто знакомые.

Наверное всё-таки библиотеки.

Рассчитаны - почему нет. Но класс и пространство имён генерируются автоматически.

И в отдельном классе - подпрограммы поддержки Паскаля (множества, файлы).

Можно заняться конечно тем, чтобы для разработчиков C# библиотеки было приятнее использовать. Я вот не знаю, есть ли такой атрибут, чтобы не показывать что-то в интеллисенс Visual Studio.

А зачем атрибуты тут? internel просто сделайте.

Да, есть такой атрибут - EditorBrowsable.

Делал заявление исходя из Вашего сообщения:

@Admin, мне кажется, @MrFresnel имел ввиду детали реализации в том плане, что для нормальной работы нужно вызывать InitModule’и:

    PABCSystem.PABCSystem.__InitModule__();
    GraphWPF.GraphWPF.__InitModule__();

От скрытия этого от анализатора кода модули сами не инициализируются, зато использовать их будет уже нельзя. Суть именно в том, чтобы InitModule’и сами вызывались если модуль-класс используется. А для этого нужно запихнуть InitModule в статический конструктор модуля-класса. Тогда и писать эти “детали реализации” для каждого модуля не придётся.

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

1 лайк

Я говорю про то, чтобы вынести раздел initialization модуля в статический конструктор класса

Всё правильно. Особо не планировали. Но подключать можно как и везде в .NET. Нейтральные библиотеки подключать неудобно из-за совпадения имени пространства имен и библиотеки - это да.

И если вы в паскаль-библиотеке используете функции вывода паскаля, то придётся вызывать код инициализации.

Но это и всё. Собственно, именно это можно немного переделать - и dll можно будет спокойно использовать. Никто не печётся о лишних 20 Кб, добавляемых в dll.

1 лайк

А где он сейчас?

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

2 лайка

Нигде. Просто встроенный метод инициализации вызывается в паскале. В C# если писать без инициализации то сразу NullReferenceException выходит. Нужно чтобы инициализация была и в статическом конструкторе

Это не поможет. Класс должен хотя бы где то использоваться для вызова его конструктора

1 лайк
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using PABCSystem;
using System.Windows.Media;
using static PABCSystem.PABCSystem;
using static GraphWPF.GraphWPF;

namespace WpfApp1
{
    class Program
    {
        public static void Main(string[] args)
        {
            //GraphWPF.GraphWPF.__InitModule__();
            Rectangle(100, 100, 600, 150, Color.FromRgb(200, 200, 200));
        }
    }
}

Это не будет работать, пока не раскомментировать строчку с инициализацией, хотя класс GraphWPF, как видите, используется.

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

С той проблемой я уже разобрался, на самом деле нужно было использовать 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 лайк