Первую issue предлагаю решить следующим образом — добавить директиву компилятора {$nestedrecords}, которая разрешит использовать конструкции вложенных записей. Про невозможность захвата имени из объемлющего объекта написать в справке (Директивы компилятора). Без директивы выдавать ошибку (или предупреждение). Директива — не самое лучшее решение, но она позволит избавиться от кучи мусора в списке ошибок и предупреждений.
Вторую Issue закрыть будет гораздо сложнее. У меня идей нет. А что я там сказал по поводу реализации захвата имени объемлющего объекта на лету — забудьте этот бред)) Я уже сам понял, насколько это будет трудно реализовать.
Всё что непросто реализовать, мы откладываем на потом - увы. В первую очередь мы исправляем явные ошибки. Таких - особенно в лямбдах - накопилось уже много.
В этих условиях на первое место выходит уже не критерий эффективности программного продукта, а трудозатраты на его разработку и последующее сопровождение – именно они определяют конечную стоимость программного обеспечения.
Фирмы-разработчики с мировым именем бесцеремонно заявляют: «Программа
медленно работает? Купите более современный компьютер или попробуйте нарастить оперативную память».
В каких этих? Современных - так в разных областях эти условия отличаются. Мега корпорации это не единственная область бизнеса.
Ничего в этом хорошего. То что у меня на компьютере игры с кастомными движками запускаются без тормозов на очень хорошей графике, но я не могу выжать >5 стабильных fps ни из 1 игры на unity на минималках… И при этом мне говорят что это у меня компьютер какой то не такой… Это просто грустно.
Как много здесь присутствующих являются частью какой то мега корпорации?
Хранение данных на стеке вместо кучи это не какое то мизерное преимущество:
type
ct = class
a, b: pointer;
end;
rt = record
a, b: pointer;
end;
begin
var sw1 := new System.Diagnostics.Stopwatch;
var sw2 := new System.Diagnostics.Stopwatch;
var c := new ct;
var r := new rt;
var lc := 10000;
var ilc := 100000;
loop lc do
begin
sw1.Start;
loop ilc do
begin
c.a := c.b;
c.b := c.a;
end;
sw1.Stop;
sw2.Start;
loop ilc do
begin
r.a := r.b;
r.b := r.a;
end;
sw2.Stop;
end;
writeln($'классы: {sw1.Elapsed}');
writeln($'записи: {sw2.Elapsed}');
readln;
end.
У меня записи в полтора-два раза быстрее тут. НО, если заменить pointer на byte - преимущество записей подскакивает почти до 6-кратного. Могу предположить что это из за оптимизаций процессоров для работы со стеком.
Но это всё про записи в целом. А к вложенным записям я отношусь довольно не однозначно:
С одной стороны в функциональном программировании это просто кошмар что то такое использовать.
С другой - это может быть полезно для “не серьёзного кода”, как дебаг, или какой то простенький проект - тест. Экономия средств может и показаться бесполезной - но если это, к примеру, код который что то меряет, что не редкость в дебаге…
В итоге - идею с директивой я поддерживаю, она помогла бы направить новичков от вложенных записей. Но при этом дать возможность использовать их правильно (если можно так выразится), тем - кто более-менее разбирается в программировании и может сам принять адекватное решение о их полезности в конкретной ситуации.
Увы, но “делают моду” именно они. Вы много знаете процессоров для персоналок, система команд которых несовместима с придуманной в одной известной мега-корпорации? Много ли пользователей персоналок работают с операционными системами, разработанными еще несколькими известными корпорациями? Много ли устройств используют чипы оперативной памяти собственной разработки? Телевизионные панели и мониторы чьи матрицы берут? На чьих матрицах работают профессиональные, да и бытовые фото и видеокамеры? А как у нас в стране операторов сотовой связи - много разных?
Это грустно, но это факт. Можете продолжать грустить, можете апгрейдить компьютер, можете купить новый. Но и только.
Вы можете в своей конторе даже убедить руководство, насколько важно писать производительный код, даже ценой удлинения срока сдачи проекта и создания более пространного и менее понятного коллегам кода. Но рано или поздно найдется человек, который “раскроет руководству глаза” и объяснит, что если завтра Вам, извините, сосулька на голову упадет с крыши, Ваш суперкод неделю разбирать будут коллеги. Или две недели. Чтобы внести пустяковое изменение.
Можно до упаду спорить о записях.
Это бесполезно, поскольку в паскале они есть.
В некоторых случаях они полезны.
Никто с этим не спорит.
Но я убеждён, что не следует без нужды усложнять язык.
Возможно, вложенные записи в каких-то случаях могут быть полезны.
Но это не повод вводить эту химеру в ЯП.
В Паскале вполне достаточно в случае нужды вкладывать записи в записи путем последовательного определения типов, так что мне тоже непонятно, зачем язык усложнять.
type
r1 = record
p1: array of real;
p2: integer;
p3: string
end;
r2 = record
s1: array of r1;
s2: DateTime;
s3: int64
end;
r3 = record
q1: real;
q2: r2;
q3: integer
end;
begin
var rr := new r3[5];
rr[2].q2.s1 := new r1[3];
rr[2].q2.s1[1].p1 := new real[2];
Writeln(rr);
end.
Остаётся мне только дополнить: хотя возможность вложения одних типов в другие есть как и в Паскале, так и в C#, но ей пользуются не так часто. Это замечание - просто факт и не влияет на мою точку зрения: я за вложенные записи, но это фича не первой необходимости. И в неумелых руках эта фича может навредить коду, как, собственно, и любая другая. Идея с директивой мне нравится тем, что позволит оградить новичков от вложенных записей, которые, скорее всего, пользовались ими бы как попало.
Если вложенные записи нужны для внутреннего пользования, то в модуле или библиотеке их можно заменить обычными, поместив в секцию implementation. С другой стороны, при данном решении этой проблемы эти записи будут видны в модуле или библиотеке даже там, где нам не хочется (если нам, конечно, этого не хочется). Поэтому, здесь не всё так однозначно, как хотелось бы.
Если говорить лично обо мне, то мне вложенные записи не пригодились нигде, кроме как для тестирования PascalABC.NET.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021