Этого кода, увы, уже нет. На 7-й день изучения программирования, разумеется, мне были неизвестны такие вещи как работа с файлами. И даже работа с массивами. Но зато очень хорошо было известно, что такое Copy&Paste. Скопировать, вставить, а потом что-то поменять в скопированном коде. Время было начало 2000-х, никто нигде ничего не мог подсказать - и Интернета нормального небыло. Спрашиваю у учительницы по информатике в школе - что делать не дает злой Турбо Паскаль писать код более 64 Кб (а у меня на компьютере целых 128 мегабайт оперативы, как так-то, что за дурацкие ограничения) - она офигела какие 64 килобайта о чем вы никогда с таким не сталкивалась, а тут уже на 7-й день ... и ничего не может предложить. Отец у своего знакомого программиста тогда спросил, что делать - он ответил, пусть разбирается с модулями. Разобралась через 2-3 месяца только, модули оказалась для меня жутко сложная штука тогда. А через год, в 11-м классе (когда уже код тоже был некрасивым, но не таким диким, как в первые дни) - ради интереса попробовала сократить этот код, что был написан - получилось в 10 раз короче исходного и делает то же самое, причем меньше глючит при этом.

В 11-м классе прикол был. Учительница информатики объясняет функция random от 10 возвращает значения от 1 до 10. Я не удерживаюсь и говорю - нет, от 0 до 9 (это мне уже после месяца начала изучения Турбо Паскаля было известно). Спорили около 5-10 минут, я продолжаю отстаивать свою позицию и не сдаюсь. Ну что делать - подошли к компу, написали программу, действительно выдает от 0 до 9. Учительница, собака, затаила злобу и поставила годовую оценку по информатике 4, а не 5. Реву было тогда много от такой несправедливости но что сделаешь учительница может знать меньше, но ведь она тебе оценки ставит, а не ты ей ...

Да это уже решилось проще - разбитием длинной процедуры на 5 более коротких. Просто неожиданно оказалось когда более старый D7 позволяет а в новом D2010 так нельзя. Рефакторинг кода - конечно, штука хорошая но в этой процедуре он особо не нужен пока.

Получается велосипед с квадратными колёсами. Но если часто парсить не надо вполне себе решение. Понятно, что при большой нагрузке такой велосипед поедет медленно. Правда, у Node.JS есть неоспоримое преимущество перед любыми сторонними компонентами Delphi - уж раз он настолько популярен - на 99,999% при таком подходе не будет проблем с багами - по крайней мере в таком простом сценарии .

По сути так оно и есть - лишние конструкции, издержки языка и структуры VCL. Кто работал в 1С - поймёт, никакого подключаемого мусора. Даже в Java можно написать что-то подобное

import java.util.*;
import java.io.*;

а не импортировать каждый модель отдельно - когда например мне как программисту не особенно интересно, как оно там технически устроено внутри VCL - главное чтобы работало.

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

Я конечно понимаю, что среда сама делает и понимаю, что бесплатно. Но очень уж хотелось бы это как-то отключить.

Я ещё понимаю - в случае если пользоваться визуальным редактором форм Delphi - чтобы среда добавляла что-то в класс формы, методы в секции implementation ну и до кучи модули в секцию USES.

Но я совершенно не понимаю - зачем среда добавляет ненужные модули в секцию USES если я просто открываю, скажем, модуль Unit2.pas - делаю там правки и сохраняю (файл-->сохранить как) - так вот, в момент сохранения среда что-то пропихивает своё в секцию USES. Хотя казалось бы, команда называется "Сохранить" - ну так и сохраняй - зачем при сохранении что то в модуле менять ?

Притом что если, скажем, файл Unit2.pas не открывать в Delphi - он этим самым Delphi прекрасно компилируется.

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

Ладно, о чём спорить - понятно, что всё использование Node.JS для парсинга JSON не от большого ума и вообще это всё лирика.

А собственно по переходу на D2010 (или вообще на любую юникодную Delphi) - как вы думаете - хорошая ли это идея - заменить во всех файлах проекта примерно так:

StringReplace('string ', 'AnsiString ', s)
StringReplace('char', 'AnsiChar', s)

StringReplace('chr(', 'AnsiChar(', s)

StringReplace(': array of string', ': array of AnsiString', s)
StringReplace('of string', 'of AnsiString', s)
StringReplace('of char', 'of AnsiChar', s)

и т. д.? Тогда в стандартных библиотеках VCL всё останется как было - тип string будет уже как WideString в новой Delphi. А в моём коде string будет заменено на AnsiString. Делал ли кто что-то подобное - это нормально при переходе на новые версии Delphi - или это очередной велосипед?

Как ни странно, если создать чистый проект и подключить мои

USES {$I AllVcl.pas};

В единственную форму - Delphi ничего не корежит, не подставляет в секцию USES и нормально компилирует.
Если же в моём проекте - несмотря на то, что в {$I AllVcl.pas} есть все нужные модули - Delphi всё равно их пехает в USES перед моим {$I AllVcl.pas}, а потом ругается, что Duplicate unit и не компилирует. Впрочем, решается всё если в AllVcl.pas прописать

{$IF not Declared(SysUtils}}SysUtils,{$IFEND}
......

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

У меня там есть переопределение класса TForm - создание наследника TForm и использование наследника TForm вместо оригинального во всех формах (чтобы иметь возможность вносить изменения централизованно, сразу во все формы - например, в заголовок добавлять дополнительный текст или не допускать вызова OnActivate более 1 раза, коррекция некоторых косяков некоторых VCL компонентов например DateTimePicker и т д). Возможно, в этом всё и дело ...

Думаю, скрипт на AutoIt или Python сделать, который будет анализировать модули и выпиливать этот мусор - совсем не проблема. Но пока не буду - проблема эта хоть и криво, но решилась другим способом с помощью {$IF not Declared(...)}...{$IFEND} и без выпиливания нормально всё работает.

А вот с before build скриптами идея интересная, надо разобраться ...

Да, во время шторма навигации как-то учиться не очень, приходится заниматься тем, что умеешь - пилить костыли. А когда шторм проходит - желание учиться тоже проходит и так ведь всё нормально можно потихоньку кодить и не думать о плохом. Так вот неправильно живём и я полагаю многие так живут :(