Зачем мне нужно инициализировать var перед перенаправлением оболочки с вызовом / ожиданием / выводом - PullRequest
3 голосов
/ 25 июня 2011

Если я попробую следующий код:

call/wait/output {webrequest http://google.com login password} content

REBOL выдает ошибку.Вместо этого я должен использовать следующее:

content: ""
call/wait/output {webrequest http://google.com login password} content

Почему?

Обновление: я думал, что ответ будет простым ...

Ответы [ 2 ]

4 голосов
/ 26 июня 2011

"Почему?"это сложный вопрос!Я попытаюсь дать обоснование ...

При возврате значения из функции, которая должна собирать данные и возвращать их, есть два основных варианта (в большинстве языков).

Один должен использовать его как return.(В таких языках, как Rebol и Ruby, неявный возврат - это то, что вычисляет последний оператор в блоке кода.) Другой способ передать данные обратно - вставить его в параметр, который вызывающая сторона передала «по ссылке» или «с помощьюуказатель ".

Текущий дизайн call заключается в том, что он возвращает код завершения процесса.Но давайте представим альтернативную вселенную, в которой уточнение до call из /output изменило возвращаемое значение, это может выглядеть так:

>> call {echo "test"}
== 0

>> call/output {echo "test"}
== [0 "test"] ; in an alternate universe...

Выбор дизайна заключался не в том, чтобы сделать это.call всегда возвращает простой код выхода.Вместо этого, если вам небезразлично /output вызова, вы передаете параметр по ссылке ..., в который Rebol запишет результаты консоли.

Это очень гибко, потому что Rebol позволяет вам (например)передайте параметр, который является открытым файлом, чтобы записать результаты ... вместо того, чтобы заставить хранить функцию, которая может быть очень большой, а затем записать ее.То, следует ли call записывать в файл или помещать результаты в строку, определяется типом данных параметра «по ссылке».

Короче говоря, это решение для языка.Вместо того, чтобы делать предположение о том, куда должен выводиться вывод, Rebol «нюхает» тип параметра и делает соответствующую вещь.Если вы не установили тип данных для content ... он не может работать.Опять же, если мы рассмотрим «альтернативную вселенную», было бы возможно для call, чтобы иметь различные уточнения:

call/outputstring {echo "test"} content

И тогда не пришлось бы беспокоиться о том, content было объявлено ранее, call предполагал, что он должен превращать содержимое в строку.Если бы вы писали в файл, он мог бы создать его для вас ... как это:

call/outputfile {echo "test"} %/myfile.txt content

Но это не позволило бы вам записать в произвольное местоположение уже существующего файла, илиположение в существующей строке.Проще говоря, требуя, чтобы content было объявлено ранее.Но, как вы заметили, требуется немного больше кода.Вы можете, если хотите, поместить объявление в строку:

call/output {echo "test"} content: {}
2 голосов
/ 01 февраля 2013

Это просто.Если вы сделаете HELP для CALL, вы увидите, что для параметра / OUTPUT требуется аргумент одного из следующих типов: string !, port !, file !, url!или нет!Когда вы просто передаете слово CONTENT, не определяя его, вы передаете unset!значение, которое не соответствует ожидаемому типу аргумента, следовательно, генерирует ошибку.

...