И правда, так должно быть проще реализовать и ближе к уже существующей реализации:
type
// false - Не создавать имена в глобальном пространстве имён
// base=typeof(byte) - тип, хранящий значения перечисления
[EnumOptions(false, base=typeof(byte))]
Месяца = (Январь, Февраль, Март);
begin
var m := Месяца.Март;
end.
Я так подумал, что ещё может понадобится отключение видимости имён вне модуля. обусловлено тем, что может возникать необходимость использовать enum в качестве параметра исключительно внутренних методов
для одновременного запуска двух программ всегда нужно танцевать с бубном, жать “сделать активным” и разделять экран по несколько раз? при чём все действия помогают ровно на 1 запуск. это известная ошибка или кнопки запуска второй программы недолжно быть в принципе?
Ну как бы да, но как вы себе представляете исправить это? Как, к примеру, запретить .Sort но не .ConvertAll?
Или если оба запрещать - то запрещать вообще всё кроме чтения элемента по индексу?
В случае констаного поля класса - берётся копия массива. Все остальные константные значения - размерны, поэтому аналогию можно провести. Ну, кроме string, которые вообще не изменяемы в .Net .
помню, что где-то можно было посмотреть реализацию методов .net но не нашёл сайт. разве там происходит перезапись? по логике должен выделяться массив такого же размера и значения исходного массива просто преобразуются в цикле или что-то типо такого. или тут проблема вообще в чём-то другом?
ну я и пытаюсь понять, в чём проблема их отличить. опять же в компиляторах я слаб и может что-то не понимаю. разве это какой-то единичный случай, когда один метод запрещено использовать? или Sort и ConvertAll похожи какой-то ключевой особенностью? какой?
Дело не в компиляторах. Создание компилятора это не использование сил четвёртого измерения чтобы добится того что не суждено познать смертным. Это написание алгоритма, как и в любой другой программе.
Отдельными сложными темами являются парсинг сложных элементов синтаксиса и затем способы преобразовать прочитанные части текста в что-то исполняемое.
Но в данном случае это не при чём:
Как бы вы написали метод, который возвращает boolean, типа можно ли этот метод вызывать на массиве-константе?
Эти 2 метода похожи тем что принимают массив - который в .Net является ссылкой на место в памяти где хранятсья элементы.
По сигнатуре метода видно что они не меняют саму ссылку (массив принимается неvar-параметром).
Но единственный способ понять, меняют ли они элементы, которые находятся по этой ссылке - смотреть на реализацию этих методов.
а, всё ясно. я просто читал ночью, когда голова уже не варила и не понял, что convert был приведён просто в качестве примера.
в целом, я так думаю, что можно при обнаружении sort проверять, как был объявлен соответствующий массив. опять же не знаю на сколько это “правильно”, если вообще применимо. понятно, что если делать так, то появятся дополнительные сложности при расширении списка подобных методов. однако оставлять в таком виде было бы тоже неправильно. как-то же компилятор должен информировать, что тут попытка отсортировать неподдающееся сортировке
это понятно. моя проблема в том, что я достаточно поверхностно понимаю процесс компиляции и не знаю классических подходов к специфическим задачам свойственным только этой сфере
Вообще я считаю что это плохо. Обычные методы и методы расширения нельзя визульно различить, не наводя на них специально мышку.
Поэтому ИМО они должны работать одинаково. К примеру в данном случае адекватнее будет выдавать что Incremental не найден - это не метод расширения для типа string.