Мнимые ошибки PascalABC.NET

И правда, так должно быть проще реализовать и ближе к уже существующей реализации:

type
  // false - Не создавать имена в глобальном пространстве имён
  // base=typeof(byte) - тип, хранящий значения перечисления
  [EnumOptions(false, base=typeof(byte))]
  Месяца = (Январь, Февраль, Март);
  
begin
  var m := Месяца.Март;
end.

Я так подумал, что ещё может понадобится отключение видимости имён вне модуля. обусловлено тем, что может возникать необходимость использовать enum в качестве параметра исключительно внутренних методов

Для этого можно описывать этот тип в implementation.

1 лайк

точно. совсем забыл про этот вариант

для одновременного запуска двух программ всегда нужно танцевать с бубном, жать “сделать активным” и разделять экран по несколько раз? при чём все действия помогают ровно на 1 запуск. это известная ошибка или кнопки запуска второй программы недолжно быть в принципе?

норм, что это вообще компилируется?

type
  f =  file of record a: integer end;
begin end.

Норм

1 лайк
const a: array of integer = (8, 4, 5);

begin
  a.Sort;
  //a.print;
end.

а это?..

Вообще поидее так же как тут должно быть:

type
  t1 = static class
    
    const a: array of integer = (8, 4, 5);
    
  end;
  
begin
  t1.a.Sort;
  t1.a.print;
end.

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

const a: array of integer = (8, 4, 5);

begin
  a[1]:= 3;
end.

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

тем более в классах фактической сортировки не происходит, так что оставлять в качестве сомнительной фичи думаю не стоит

Ну как бы да, но как вы себе представляете исправить это? Как, к примеру, запретить .Sort но не .ConvertAll?
Или если оба запрещать - то запрещать вообще всё кроме чтения элемента по индексу?

В случае констаного поля класса - берётся копия массива. Все остальные константные значения - размерны, поэтому аналогию можно провести. Ну, кроме string, которые вообще не изменяемы в .Net .

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

Реализацию можно смотреть на referencesource, но тут она не нужна - описания на msdn, или даже в подсказе в IDE паскаля достаточно.

Проблема в том, как отличать эти методы, чтобы запретить .Sort, но не ConvertAll.

ну я и пытаюсь понять, в чём проблема их отличить. опять же в компиляторах я слаб и может что-то не понимаю. разве это какой-то единичный случай, когда один метод запрещено использовать? или Sort и ConvertAll похожи какой-то ключевой особенностью? какой?

Дело не в компиляторах. Создание компилятора это не использование сил четвёртого измерения чтобы добится того что не суждено познать смертным. Это написание алгоритма, как и в любой другой программе.

Отдельными сложными темами являются парсинг сложных элементов синтаксиса и затем способы преобразовать прочитанные части текста в что-то исполняемое.
Но в данном случае это не при чём:
Как бы вы написали метод, который возвращает boolean, типа можно ли этот метод вызывать на массиве-константе?

Эти 2 метода похожи тем что принимают массив - который в .Net является ссылкой на место в памяти где хранятсья элементы.
По сигнатуре метода видно что они не меняют саму ссылку (массив принимается не var-параметром).
Но единственный способ понять, меняют ли они элементы, которые находятся по этой ссылке - смотреть на реализацию этих методов.

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

в целом, я так думаю, что можно при обнаружении sort проверять, как был объявлен соответствующий массив. опять же не знаю на сколько это “правильно”, если вообще применимо. понятно, что если делать так, то появятся дополнительные сложности при расширении списка подобных методов. однако оставлять в таком виде было бы тоже неправильно. как-то же компилятор должен информировать, что тут попытка отсортировать неподдающееся сортировке

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

и ещё обнаружил, что вот это не работает

## ('asdfg').Incremental;

Нет перегруженной подпрограммы с такими типами параметров

но ведь тут функция вызвана вообще без параметров :thinking:

‘asdfg’ для этой функции - параметр

естественно, у расширения первый параметр записывается префиксом до точки

Вообще я считаю что это плохо. Обычные методы и методы расширения нельзя визульно различить, не наводя на них специально мышку.

Поэтому ИМО они должны работать одинаково. К примеру в данном случае адекватнее будет выдавать что Incremental не найден - это не метод расширения для типа string.