27.06.2012 12:20, Igor Chumak пишет:
> 26.06.2012 23:26, "Артём Н." пишет:
>> 26.06.2012 23:26, Dmitrii Kashin пишет:
>>> "Артём Н."<[email protected]> writes:
>>>
>>>> Глобальные переменные сильно увеличивают связность и вероятность появления
>>>> ошибок, в результате их случайного переопределения, например.
>>> Не надо переобределять глобальные переменные в теле программы.
>>> Один раз установили при старте сценария - и больше не трогаете.
>> Ну так, это не переменные, а константы.
>>
>>> Если поведение функций зависит исключительно от этих переменных - Вы тем
>>> самым обеспечите их чистоту. Чем не вариант?
>> Не очень хорошо, что "интерфейс" функции "разбит" на две части.
>>
>>>> К тому же, функция их использующая, не совсем рентабельна: её не
>>>> всегда возможно вызвать без лишних движений из самой себя или из
>>>> внешней функции, если та пользуется теми же переменными (например,
>>>> придётся использовать стек или локальные переменные для сохранения
>>>> глобальных перед вызовом).
>>>> Для констант, хотя, это не актуально..? O.o
>>>> Но, тем не менее, получается, что "интерфейс" функции не сосредоточен
>>>> в одном месте, а в какой-то степени "разбросан", что не есть хорошо (и
>>>> естественно, связность между функцией и внешним окружением
>>>> повышается).
>>> Не понял ничего. Снизойдите.
>> o.O Что непонятного? Если про переменные говорить?
>> 1. Есть функция, которая вызывает другую функцию. В обеих используется одна
>> и та
>> же переменная (не для связи между ними). Если внутренняя функция её
>> переопределяет, внешняя должна сохранять.
> С архитектурой совсем плохо. Зачем переопределять глобальную переменную, если
> ее
> же переопределять нельзя, потому что если переопределили - надо восстановить?
> В bash есть и локальные переменные ;)
Facepalm. Я не использую глобальные _переменные_ там, где не нужно. В данном
случае, я их не использую вообще. Это не мой случай. Это ответ на вопрос.
>> В общем случае (к башу неприменимо)
>> ещё с многопоточностью проблемы будут. Вообще-то, это везде написано... Надо
>> объяснять? Для констант неприменимо.
>> 2. Глобальная переменная может быть случайно переопределена где угодно.
>> Кстати,
>> даже непреднамеренно (ну eval какой-нибудь неправильно использовал или что
>> ещё).
>> Поиск ошибки затянется. В случае с readonly - проблема отпадает.
> Задавайте значения глобальных переменных таким образом , чем не аналог
> read-only
> переменных?
> #!/bin/bash
> SET()
> {
> var=$1
> val=$2
> echo "set $var to $val"
> eval $var="$val"
> }
>
> SET ZZ_aa "abc"
> echo $ZZ_aa
>
> Попытки сдуру переопределить переменную ловятся grep'ом
1. Для начала надо понять, что ошибка связана с переопределением.
2. Я не конкретно про bash писал.
3. А кто сказал, что в общем случае имя переменной не может динамически
формироваться?
>> 3. Ещё раз про интерфейс. Касается и констант. Он разбит на две части. Это
>> значит, что одна переменная может влиять на несколько функций сразу, что
>> может
>> привести к побочным эффектам и трудноуловимым ошибкам (в общем случае).
>> Когда, с
>> параметром функции всё понятно (если функция "чистая", т.е. без побочных
>> эффектов): изменил, сдохла, - проблема в ней или вызываемых с этими
>> параметрами.
>> Здесь: изменил, сдохла, проблема может быть в нескольких функциях,
>> использующих
>> переменную, или в их взаимодействии. Это первое.
>> Второе из первого. Не сразу очевидно какая функция, какую переменную
>> использует.
>> Без глобальных констант, если есть иерархия вызовов, понятно какая функция,
>> что
>> использует ещё на верхнем уровне. В случае использования глобальных констант
>> -
>> непонятно. Значит, нужно использовать поиск (например, разбирая скрипт),
>> чтобы
>> найти какая переменная в какой функции используется. Понимание усложняется.
>> Но в bash нет именованных параметров у функций. При их наличии, такого
>> вопроса,
>> скорее всего, не возникло бы.
>>
> Если задача решается средствами шелла плохо и сложно - надо либо менять
> постановку задачи, либо инструмент.
Задача, как раз, для шелла. Просто именованные параметры, как мне кажется, были
бы не лишними. :-)
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
