Тогда, может, стоить переоткрыть тот Issue, назначив ему label wontfix? Как соберетесь с силами - так закройте ее.
Ну скажем - болтать так болтать:
function f: ()->()->integer := ()->begin Result :=()->1; end;
begin
var x: ()->integer;
x := f;
x := f();
x := f()();
Print(x.GetType);
var y : ()->()->integer;
y := f;
y := f();
y := f()();
Print(y.GetType);
end.
Это по-нашему означает “никогда не реализуем”
y := f()();
это не правильно, и ошибку выдаёт, как и ожидалось.
Да, это ж болталка
begin var a:=Arr(1,2,3); var b:=a; println(a); b[0]:=a[1]; println(a); end. почему так?
Собственно, что “почему так”? все нормально… [1,2,3] [2,2,3]
потому что динамические массивы при присваивании не копируются.
спасибо, за ответ. Как скопировать тогда?
Прямо из текста Справки, которую Вы почему-то погнушались почитать: ))))
Чтобы одному динамическому массиву присвоить копию другого массива, следует воспользоваться стандартной функцией Copy:
a1 := Copy(a2);
Будем ждать. Сдавай! (с)
Если уж эта возможность настолько портит нервы, что “как обычно”, почему бы эту возможность вообще не убрать? Оно ж не только на уровне грамматики кашу создает, в голове тоже. Поди-ка поля структур от последовательного вызова методов отличи… Стандарту “старого Паскаля” тут все равно никто соответствовать не стремится, разве нет? Мы тута на работе, чтоб о таких мелочах не думать, даже неконстантные ссылки не используем, чтобы лишний раз указать на смысл аргумента функции:slight_smile:
Но все же, чем меньше будет отходов от стандарта, тем правильнее. К тому же, мы не забыли, что совместимость со “старым Паскалем” пока что должна быть близка к 100%, ибо школьники… ?
Т.е. прекрасны новые широкие возможности и надо их всячески стараться при случае “воткнуть и показать”, но все же совместимость - она пока очень важна.
Ну, как это там во “взрослых” системах делается? 5-6 версий подряд кидается ворнинг с большими красными буквами DEPRECATED, потом убрать. И не обидеть никого, и избавиться от старого (и, по моему скромному мнению, очень вредного) наследия. Если ошибка будет говорящей(т.е. что-то вроде "За вызовом функции без параметров должны следовать пустые скобки. Объяснение данным изменениям здесь: [link]), то и пройдет гладко.
“Ворнинг мне бумага джаммед” (некогда - одно из сообщений болгарского IBM PC XT “Правец”)
Все это уже обсуждалось в другой ветке. И вроде как пришли к выводу, что ворнинги можно делать, но избавляться от тяжкого наследия рано. Ибо как все школьные учебники, поскольку они есть школьный катехизис, содержат пока что именно “тот” Паскаль и получив несовместимость мы вызовем автоудаление продукта PascalAВC.NET из школ.
Ну и главное: вот Вам не нравится возможность не лепить идиотические пустые скобки после имени функции, а мне очень даже импонирует. Тем более, что в свое время довелось довольно долго сидеть в клиентских проектах на VBA, а там пустые скобки при вызове функции факультативны - вот за подобные вкусняшки я мелкомягких ребят уважаю. (“И увидел он, что это хорошо” ©)
{$reference axis_api.dll}
uses AXIS;
...
begin
var IP := '192.168.0.42';
var cam: Camera := Camera.get(IP);
...
for var i:=1 to 100 do begin
cam.nextPosition;
var zoom := cam.zoom;
...
//обработка зума, например, с целью рассчитать примерное расстояние до объекта
//или требуемый угол поворота, дабы свернуть на половину экрана для каждой позиции
//вариантов тут куча
end;
...
end.
Ну, с nextPosition все понятно. Вопрос такой. zoom - это значение, которое моментально считается из поля(например, вычитываемое из камеры в параллельном потоке), или же вызов синхронного сетевого запроса, который повесит GUI-поток на время выполнения? А если кабель отошел, пользователю 30 секунд стандартного таймаута на повисший GUI лицезреть? А там таких 100 А программист-то и не в курсе… Прошу заметить, что пример-то не резиновый: прямо сейчас тут над обработками данных с камеры работаю.
P.S. Да, оффтоп. Тут пора сообщения в другую тему двигать
Вы даете в качестве примера фрагмент плохо написанной программы и предлагаете мне угадать, что означает тот или иной фрагмент в ней. По меньшей мере, некорректно. Если это Ваша программа - пишите её так, чтобы было все понятно. Если чужая и Вам доступен текст - разберитесь и вставьте комментарий, чтобы больше не подпрыгивать. Но вообще, если чужая, её в таком виде не должны были к эксплуатации принимать.
Я в жизни принимал участие во многих больших проектах, очень больших. И, поверьте, знаю, какие требования выдвигаются к программным кодам, Этот код для неспециалиста в предметной области, для которой код предназначен, непонятен. А для специалиста - ну пусть он и судит, как надо писать. Но уж точно тут не проблема наличия скобочек.
да, я тоже не люблю вызовы без функций и стараюсь всегда писать (). ибо кровушки попили они изрядно, причем толку от этой “фичи” ноль.
Типичный пример - недавнее “исправление” “ошибки”
a.Select(x->x.ToString)
Это вот проекция куда - на строку или на делегат?
Видимо зависит от пристрастия к тем или иным языкам. Лепить пустые скобки - типично сишная привычка. Т.е. если человек привык писать со скобками - ему хочется эти скобки, если привык писать без пустых скобок - ему эти скобки похуже красной тряпки быку. Вот представьте: я последние ДВАДЦАТЬ с лишним лет не работал с С-подобными языками. Вот они мне не были ни разу нужны по работе. Пустых скобок не писал вообще - так тоже бывает. Попробуйте понять мою точку зрения - будут раздражать после такого периода обязательные пустые скобки?