Можно ли обратится к области видимости того места, откуда вызвана функция? Что бы эта функция работала с переменными в той области видимости. Как это делают некоторые встроенные функции и операторы, например

Обратите внимание на my $_ ... Print работает именно с той областью видимости, в которой он находится.

Не уверен что речь об этом, но может поможет:

Ответ "вообще" - да, можно. Другой вопрос, зачем вам это надо? Т.к. существует как минимум 3 способа работать с "вышестоящими" переменными. И реальное "залезание вверх по стеку" - мне понадобилось только 1 раз, когда я писал свой стектрейс. Попробуйте описать задачу.

Например иногда надо вставить в модуль функцию, работающую в том же адресном пространстве, что и вызывающая её функция. Но я думаю, что вопрос автора просто неправильно сформулирован и ему хотелось чего-то другого.

Как это сделать? Я не нашел.

Нужно для написания библиотечных функций. Например таких, которые используют переменную по умолчанию $_.  Нужно учесть, что переменная $_ может быть обьявленна как my.

Если речь только о $_, то в 5.10 есть прототип "_" - то, что надо. Единственное ограничение - после него не может быть обязательных параметров.

В том то и дело, что список он не принимает.

Т.е. как-то так:

sub bar{}
my @foo = qw();
bar; #и оно как-то узнало, что вызывается с аргументом @foo ?

Имхо, это очень плохая и неочевидная функция. Лучше, всегда лучше, явно указывать, что ф-ция принимает в качестве параметров - код должен быть самодокументирущимся.

Но если очень хочется прострелить ногу - вуаля - cpan://PadWalker

К сожалению, перл не приспособлен к написанию документации на функции...

А насчёт $_ - уже несколько лет где-то я встречаю рекомендации эту переменную не использовать.

в смысле "не приспособлен"?
и где вы встречаете такие странные рекомендации?

Это тема для другого топика.




Сходу и не найду где. Но это рекомендации естественные, а не странные. Глобальная переменная, в некоторых версиях перла использование замедляет программу, снижает читаемость. В коротких скриптах использовать удобно, в больших появляются проблемы.

хотя бы кратко...


в каких версиях?

Это очевидно для любого, работавшего с php или java, дадаже JavaScript. Попробуйте добиться удобства описания функций и модулей, например в Eclipse, сравнимого с описанием для php, java, javascript.
В POD нет ни единого стиля, ни единых форматов, все описывают как хотят, в результате огромная часть документации нечитаема.



Долго changelog'и читать, не буду.

>работавшего с php
:

perldoc perlpod не помогает?

все описано нормально и понятно, доступ к информации удобный.

не могли бы вы показать мне аналог perldoc -m для java?


ну хотя бы покажите мне рекомендацию не использовать $_...

DurRandir спасибо, то что надо.


Не глобальная а локализованная везде, где можно. Теперь вот и локальной может быть, хотя от этого ИМХО только неприятности. Читаемость может улучшать, а может снижать, это уж как использовать. В больших скриптах тоже можно использовать, но только не надо далеко разносить ее заполнение значением и обработку. Это действительно снижает читаемость и чревато ошибкам. Юзать ее надо рядом с местом локализации, тогда читаемость улучшается.
На счет замедления в некоторых версиях тоже в первый раз слышу.
 

Простой тест:



Результаты:


Разница заметна?

А есть ещё my $_ и our $_ - и результат будет тоже интересный, особенно в разных версиях.

Это сообщение отредактировал(а) mvsgt - 26.1.2010, 23:07

Пока не зачет. Замените либо $_ на my, либо $i на our. Результаты сравняются.

А так это доказывает лишь то, что лексические переменные здесь быстрее, чем динамические.

а сделайте-ка мне my $_ в 5.6 . Получится? Я не зря писал про некоторые версии и тестировал именно эти самые некоторые, в которых ещё не было my $_.
$_ имеет смысл упоминать именно в том виде, в котором её все знают. Иначе встретятся чудеса (пример ниже), когда возникает потребность понять что за $_ будет использована. И тестировать производительность имеет смысл для тех случаев, которые встречаются в жизни. my $_ - не встречается.

Там просто $i сделайте динамической и протестируйте.


  Наоборот - ты проверяешь, какие результаты, а на основании них делаешь вывод о том, будет ли нечто встречаться у тебя в жизни, или нет.

то есть я  должен начать доказывать утверждение, которого я не делал? Зачем?



Наоборот - я залез в мою установку перла и посмотрел, сколько модулей использует my $_ - один модуль, причём я так и не понял зачем. Так вот, я сначала сделал предположение, затем его проверил. Это правильный путь. Вы же ни того, ни другого не сделали.