>>70017
Слышь, попутал, паскаль охуенен.

Во-первых, PascalABC НЕ НУЖЕН: это (слегка) замаскированный C#, в котором от Паскаля часть синтаксиса и всё. Соответственно, нет абсолютно никакого смысла писать на нём вместо C#, даже для обучения: он НЕ ПРОЩЕ, в качестве синтаксиса имеет кашу из обоих языков и НЕ КОМПИЛИРУЕТСЯ В НАТИВНЫЙ КОД. New и сборка мусора в Паскале, охуеть просто, это полностью противоречит его философии, точь-в-точь те ебанутые .NET-надстройки над C++ с ref new и прочей неведомой дичью, на которых никто не пишет, потому что это ебланство. Единственный не ебланский язык для .NET — C# (на F# не уверен, что пишут не одни сойбои с целью сублимировать желание отсосать друг дружке), потому что он создан с нуля под возможности .NET, а встраивание другого языка/платформы поверх и без учёта того, что в языке уже есть, даёт заведомо мертворождённый результат; ну а единственный человеческий Паскаль на сегодняшний день — Free Pascal, в его контексте я и буду говорить.

Прежде чем вернуться к Паскалю, рассмотрим твой случай.
Твоя проблема — вернуться куда-то сквозь тонны репитов и кейсов-оф, говорит о том, что ты всё, всё сделал не так, и ровно ту же дичь написал бы на любом другом языке.
Попробуем сделать лучше.

У нас будет МИР (у меня TWorld) — штука, перманентно хранящая глобальное состояние, что там наш персонаж натворил и т. п.
У нас будет СЦЕНА (у меня TScene) — штука, отвечающая за конкретную локацию: за её отображение и обрабатываемые ей команды (пойти туда-то и т. п.).
(Плохие названия, мне похуй.)
Чтобы не усложнять, текущая СЦЕНА будет храниться в самом МИРЕ. Тогда у МИРА будет метод SwitchTo(TScene), который переключит его на новую сцену. Например, если текущая сцена — Комната А, и из неё есть проход в Комнату Б, то для выполнения перехода мы сделаем world.SwitchTo(RoomB.Create).

Кроме того, СЦЕНА будет сообщать свои команды специальной виртуальной функцией HandleCommands, чтобы можно было объединить называние и обработку команды в одном месте в коде (с анонимными функциями делать так бы не пришлось :):
procedure MyScene.HandleCommands;
begin
　　if Command('1', 'вырастить крылья') then World.SwitchTo(Scene_GrowWings.Create);
　　if Command('2', 'убежать') then World.SwitchTo(Scene_RunAway.Create);
end;
Где Command возвращает ложь, если сам факт вызова Command сказал супервизору достаточно (имя и описание) и больше ничего делать не нужно, и истину — если команду нужно выполнить.

Ну а точка входа нашей программы будет выглядеть просто как
begin
　　world := TWorld.Create(FirstScene.Create);
　　try
　　　　while world.Alive do
　　　　begin
　　　　　　world.Display;
　　　　　　readln(cmd);
　　　　　　world.SendCommand(cmd);
　　　　end;
　　finally
　　　　FreeAndNil(world);
　　end;
end.
Ну и будем делать конкретные сцены (для разных комнат и т. п.) наследниками TScene, переопределяющими методы HandleDisplay и HandleCommands, хотя это не промышленный способ. Промышленным будет сделать единственный класс TScene и выражать различия между разными комнатами не кодом наследников, а данными, хранящимися в полях TScene — это может быть текст экрана, действия, условия для появления всего этого и всё такое. Представь, как просто будет во втором способе вынести описания разных комнат во внешние файлы, и как геморройно в первом. Или, например, в другой раз 100500 монстров могут быть реализованы не 100500 классами, а единственным классом TMonster, хранящим портрет, характеристики, умения, флаги поведения и всё такое, что, опять же, позволит отделить данные — описание монстров — от логики приложения.

В итоге у нас получается что-то такое: https://ideone.com/aO1H4z.

Теперь вернёмся к Паскалю. Чем Паскаль охуенен? А ровно одной вещью, и имя ей —
ЭНУМЫ.
Бля, энумы в Паскале — лучшее, что там было и, боюсь, будет.
В реальном мире часто возникает выбор из нескольких дискретных вариантов, и энумы замечательно это моделируют.
Например, мы можем сделать энум-тип местности (трава, грязь и т. п.), создать константный (или обычный) массив записей-характеристик этой местности и индексировать его этим энумом: https://ideone.com/8CjFSb.

Охуенно же. Супер-полезно и удобно. Если ты попробуешь сделать то же самое в любом другом языке, ты гарантированно обосрёшься под себя. Либо язык потребует явных преобразований между целыми числами и энумами, либо проверка типов будет, наоборот, недостаточно строгой, либо массив будет на самом деле хеш-таблицей или ещё какой-нибудь тормозной хуитой. В Паскале энум = число, и наш массив — простой и супер-быстрый линейный блок данных в памяти.

Чем же Паскаль плох?
— Паскаль сравнительно непопулярен. По причине непопулярности проблемы с утилитами, библиотеками, багами и недоработками компилятора, оболочки Lazarus и т. д. могут возникать чаще, чем в более массовых языках, это заколдованный круг.

— ОЧЕНЬ МЕДЛЕННЫЕ СТРОКИ (динамических массивов в меньшей степени тоже касается). Ходят слухи, что даже в JavaScript, если постараться, быстрее (я в это не верю, но мне лень проверять). Проблема отчасти в их copy-on-write'ности и счётчиках ссылок (первая часть доклада https://www.youtube.com/watch?v=rJWSSWYL83U — 2:30–24:22 — этому посвящена). Так что, например, если ты разделяешь какой-то текст по словам, каждое слово вырезаешь и куда-то передаёшь — тобi пизда, во всяком случае, ручная работа через PChar будет быстрее на порядок, если не два. Я специально в пока не обнародованной переделке своего движка сделал тип StringView (см. стандартный класс string_view в C++) и другие обходные пути, чтобы не работать с честными строками, когда возможно (StringView позволяет сослаться на фрагмент существующей строки без создания новой, без подсчёта ссылок и проч., например, чтобы передать его куда-нибудь для обработки, и при этом с ним можно работать во многом как с обычной строкой — сравнить с другой, пройтись по символам, вырезать подстроку...).　Впрочем, это касается абсолютно всех языков... и вообще-то без счётчиков ссылок (или с иммутабельными строками, как в .NET), как правило, всё ЕЩЁ хуже :).

(К строкам же: разделены «юникодные» (unicodestring, UTF-16) и однобайтовые (【ansi】string) строки, мне приходится использовать хак, чтобы забить на «юникодные» и хранить в «однобайтовых» строках UTF-8, потому что я ненавижу UTF-16.)

— НЕТ (человеческого) RAII. Для неуправляемого языка это полное дно. Управляемые типы, такие как array of и string, уничтожаются автоматически, но пользовательские классы (и другие динамически выделенные структуры) нужно освобождать вручную. Для классов, которые существуют в рамках функции (как world выше) — это означает постоянно повторять бойлерплейт с Create-try-finally Free. (В Free Pascal утечки памяти отслеживаются модулем heaptrc.)

— НЕТ ШАБЛОНОВ. Дженерики — немощная, а то и забагованная, хуита, хотя в Delphi вроде чуть лучше. В Free Pascal нет вывода типов для generic-функций, что убивает половину идеи: если у тебя есть generic-функция Max<T>(const a, b: T): T, то её нельзя вызвать как Max(2, 3) — только как Max<integer>(2, 3), а в исконном Free Pascal-синтаксисе и вовсе specialize Max<integer>(2, 3).

— НЕТ АНОНИМНЫХ ФУНКЦИЙ. В Delphi есть, но медленные, и вообще Delphi для пидоров.

Но для любого языка любой пишущий на нём достаточное время набросает тебе такой же список проблем.
А энумы останутся!

>>70342
Ещё такая тема. Я сказал, что человеческого RAII нет, но контрчеловечный таки есть, и его стоит использовать.
Сразу квестик, переделанный без ручного уничтожения объектов: https://ideone.com/SRWpVw. Сейчас объясню по порядку.

Переменные-объекты классов — это голые указатели, работа с одними ними не подразумевает никакой магии компилятора, кроме разве что неявного разыменования при обращении через «.». В том числе, как уже говорилось ранее, они не освобождаются автоматически. Так что
type
　　PMyRecord = ^TMyRecord;
　　TMyRecord = record
　　　　x: integer;
　　end;

　　TMyClass = class
　　　　x: integer;
　　end;

var
　　rec: PMyRecord;
　　cls: TMyClass;

begin
　　new(rec);
　　rec^.x := 5;
　　writeln(rec^.x);
　　dispose(rec); rec := nil;

　　cls := TMyClass.Create;
　　cls.x := 5;
　　writeln(cls.x);
　　FreeAndNil(cls);
end.
— это принципиально одно и то же (ну, с точностью до фич class, которые здесь не важны).

Но в Паскале есть интерфейсы. Они изначально введены для совместимости с Microsoft'овской технологией COM — понятия не имею, что это такое, но сама она нас не интересует, и это не привяжет нас к Microsoft-платформам — на рассматриваемом уровне это просто тоненький бинарный стандарт. Важны только некоторые следствия.

COM как раз предполагает общение объектов через ~интерфейсы~, наследуемые от общего предка — IUnknown, которому полагается иметь 3 метода:
— QueryInterface — спрашивает у объекта его интерфейс по уникальному идентификатору (GUID). Это позволяет языку реализовать операции is и as для интерфейсов. Нам это не нужно, и GUID нашим интерфейсам можно вообще не указывать.
— AddRef — сообщает, что ты удерживаешь новую ссылку на объект.
— Release — сообщает, что ссылку ты больше не удерживаешь.

Так что IUnknown предполагает управление временем жизни объекта через подсчёт ссылок. Чтобы упростить работу с ним, интерфейсы сделаны управляемыми типами (как и string и array of), при работе с которыми компилятор автоматически дёргает AddRef/Release в нужные моменты. Например:

var
　　a, b: IMyInterface;
begin
　　a := b;
end;

— как и с присваиваниями string'ов, невидимо распишется в b.AddRef; a.Release; pointer(a) := pointer(b). А когда переменная интерфейсного типа выходит из области видимости, или когда уничтожается структура (класс, массив), элементом которой она была — автоматически вызывается Release.

В Паскале стандартный класс TInterfacedObject реализует IUnknown, ведёт счётчик ссылок для него, и при Release'нии последней ссылки уничтожает сам себя.

Отсюда идея — отнаследовать все классы от TInterfacedObject, ввести к каждому классу зеркалящий его интерфейс, и после создания объекта работать с ним (только) через интерфейсы.
Сделаем ГРЯДКУ с ОВОЩАМИ на интерфейсах.
ГРЯДКА будет хранить список ОВОЩЕЙ, а каждый ОВОЩ — ссылку назад на ГРЯДКУ, с искусственной целью получить её имя.
https://ideone.com/XfM8ZG
Память при этом утекает — видно, что деструкторы объектов не выполнились. В отличие от полноценной сборки мусора, счётчики ссылок обманываются циклически связанными структурами.
Этого, однако, легко избежать. Разорвём циклическую зависимость, сделав ссылку из ОВОЩА назад на ГРЯДКУ слабой, т. е. неподсчитываемой — TVegetableGarden вместо IVegetableGarden.
https://ideone.com/TqMVTj
Теперь всё работает, и объекты освобождаются автоматически.

Это вполне промышленное решение (я видел свежий, в пределах года, пример проекта на хабре, в котором ВСЕ классы так сделаны, но, блин, потерял ссылку :|). И, наоборот, неиспользование подсчёта ссылок сильно усложняет жизнь. Представь, что ты высадил на грядку 3 овоща, про 2 из которых хочешь забыть (доверить грядке самой уничтожить их в своём деструкторе), а ссылку на третий, наоборот, планируешь оставить себе, чтобы впоследствии, уже после уничтожения грядки, спросить у него, как ему рослось. Счётчики ссылок разруливают вопросы с владением автоматически. Без них тебе пришлось бы придумывать способ явно указать грядке, что она должна уничтожать, а что — нет, и так в каждом новом случае.

Но всё равно это как-то не очень здорово в плане адского бойлерплейта и форсированной работы через интерфейсы. Можно поступить хитрее.
Будем всё так же наследовать наши объекты от TInterfacedObject ради подсчёта ссылок.
Но парные интерфейсы мы создавать не будем и вообще работать через интерфейсы не будем. Вместо этого объявим единственный тип Reference — псевдоним для IInterface (= IUnknown).

Удержание Reference будет символизировать удержание сильной ссылки.
Всем, кто логически ~владеет~ объектом, нужно удерживать Reference на него.
Когда в такую Reference присваивается объект, она автоматически инкрементирует его счётчик ссылок, а когда Reference выходит из скоупа или переприсваивается — декрементирует.
Нужно хранить их рядом и аккуратно следить, чтобы, когда мы заменяем объект другим — переприсваивать связанную Reference. Поэтому такие переменные разумно делать приватными полями классов, работа с которыми скрыта за вызовами методов.
Если нужна слабая ссылка — просто работаем без Reference.

Получается так: https://ideone.com/F31c7M.

Ну и вот, похоже, это лучшее, что можно предложить.

Это решение хорошо тем, что оно так-то вообще не завязано на интерфейсы, а просто эксплуатирует факт их управляемости. Так, в транке Free Pascal сделаны https://wiki.freepascal.org/management_operators — возможность превратить свой record в управляемый тип, с пользовательскими инициализацией, финализацией и копированием (НАКАНЕЦТА БЛЯТЬ), и вместо интерфейсной переменной Reference может быть реализован и таким record'ом с перегруженным operator :=.