Я бы даже обобщил: во сне, в принципе, нельзя получить информацию, которой у тебя еще нет.
Потому все попытки чтения во сне сводятся к двум исходам:
а) смотришь на буквы и уже «магическим» способом знаешь, что там написано, не читая;
б) пытаешься прочесть и видишь высокоэнтропийную последовательность букв, собранных в группы, напоминающие слова.
Мне непонятен выод. %)
Глобальные данные можно из чего угодно менять, только не стоит этого делать без крайней необходимости. А эта крайняя необходимость приходит крайне редко. Из чего можно сделать вывод, что если для реализации какого-либо алгоритма приходится использовать глобальные данные, то либо Вы хотите чего-то странного, либо стоит переформулировать алгоритм.
> Разницы между первоклассной функцией и объектом не сильно много.
Разница в читабельности кода.
> Я все еще жду объективных причин не использовать замыкания.
Речь шла о локальных функциях, модифицирующих внешние данные. Уже после кто-то передернул тему на замыкания, а я повелся…
Менять внешние данные — зло, потому что если функа, которая их модифицирует длиннее 1 строки, или этих фунок несколько (о ужас!), то искать кто и когда поменял эти данные придется грепом или отладчиком, а не глазами.
А теперь о замыканиях: замыкание есть частный случай использования техники, которая делает код нечитаемым, и которую я описал выше. В гомеопатических дозах, таких, как замыкание, это допустимо, но не более. Замыкание — это уже устоявшаяся конструкция, поэтому ее можно, а
int a=0;
void incA(void) {
a++
}
incA();
нельзя. Так же как вывернутые объекты можно, а паралелльные массивы нельзя.
> Лол. Тоже самое можно сказать и про объекты: они неким магическим образом обрабатывают данные лежащие за их пределами. Объекты — зло!!11
И что же это они модифицируют за их пределами??777 ;)
При условии, что someshit() и doFoo() тривиальны, читабельность кода, практически, не страдает. В любом другом случае размотать клубок из модифицируемых переменных, определенных одним или (не дай бог) двумя уровнями выше будет сложно.
Конечно, будет.
Почему не вернуть объект вместо функи, которая неким магическим образом обрабатывает данные данные лежащие за ее пределами и при этом не переданные ей в качестве аргументов?
>И как из этого следует, что замыкание — зло? Противоречит вашей религии?
Вдогонку про Perl и потроха: можно еще вывернутые (inside out) объекты использовать. Но, фактически, вывернутый объект — это набор параллельных массивов, что тоже, в общем случае, есть зло, несмотря на то, что паттерн.
Для любого из пунктов, описанных выше, можно найти контрпример, когда единственно верным решением будет нарушение «постулата о красоте кода». Однако, это не означает, что этими контрпримерами можно оправдывать уродство кода.
Замыкания — это неизбежное зло, с которым приходится мириться, потому что некоторые языки, не предоставляют некоторых возможностей. Например, невозможно в Perl-е скрыть потроха объекта иначе, как замыканием.
Кроме того, это зло давно уже стало паттерном.
Но за веши вроде:
int someshit() {
int theData;
...
int doFoo() {
# делаем что-то c theData
...
}
...
int doBar() {
# делаем еще что-то с theData
...
}
...
doFoo();
...
doBar();
...
return theData;
}
Использование локальных данных внешней функи во внутренних, как раз, говорит о том, что деление кода на блоки не продумано. Чем использование данных внешней функции отличается от передачи данных через глобальную переменную?
Единственный случай, когда можно использовать данные из внешнего блока — это внутри коллбэка, да и то, только тогда, когда автор кода, зовущего коллбэк не позаботился о передаче дополнительных параметров.
Не забывайте, каждая функция должна выполнять только одно действие.
Горячий эспрессо — 100 руб
Горячее экспрессо — 50 руб
и наблюдать, как grammar nazi продают свои принципы. :))))
P.S. идея не моя, подсмотрел где-то
Потому все попытки чтения во сне сводятся к двум исходам:
а) смотришь на буквы и уже «магическим» способом знаешь, что там написано, не читая;
б) пытаешься прочесть и видишь высокоэнтропийную последовательность букв, собранных в группы, напоминающие слова.
Мало того, у Microsoft тоже была подобная ОС — Xenix — правда, быстро закончилась.
[InternetShortcut]
URL=http://rutracker.org/forum/viewtopic.php?t=4228361
habrahabr.ru/blogs/development/59570/#comment_1619770
Глобальные данные можно из чего угодно менять, только не стоит этого делать без крайней необходимости. А эта крайняя необходимость приходит крайне редко. Из чего можно сделать вывод, что если для реализации какого-либо алгоритма приходится использовать глобальные данные, то либо Вы хотите чего-то странного, либо стоит переформулировать алгоритм.
Вы сами-то поняли, что хотели сказать? ;)
Разница в читабельности кода.
> Я все еще жду объективных причин не использовать замыкания.
Речь шла о локальных функциях, модифицирующих внешние данные. Уже после кто-то передернул тему на замыкания, а я повелся…
Менять внешние данные — зло, потому что если функа, которая их модифицирует длиннее 1 строки, или этих фунок несколько (о ужас!), то искать кто и когда поменял эти данные придется грепом или отладчиком, а не глазами.
А теперь о замыканиях: замыкание есть частный случай использования техники, которая делает код нечитаемым, и которую я описал выше. В гомеопатических дозах, таких, как замыкание, это допустимо, но не более. Замыкание — это уже устоявшаяся конструкция, поэтому ее можно, а
int a=0; void incA(void) { a++ } incA();нельзя. Так же как вывернутые объекты можно, а паралелльные массивы нельзя.
> Лол. Тоже самое можно сказать и про объекты: они неким магическим образом обрабатывают данные лежащие за их пределами. Объекты — зло!!11
И что же это они модифицируют за их пределами??777 ;)
Конечно, будет.
Почему не вернуть объект вместо функи, которая неким магическим образом обрабатывает данные данные лежащие за ее пределами и при этом не переданные ей в качестве аргументов?
>И как из этого следует, что замыкание — зло? Противоречит вашей религии?
Из этого следует его неизбежность.
Для любого из пунктов, описанных выше, можно найти контрпример, когда единственно верным решением будет нарушение «постулата о красоте кода». Однако, это не означает, что этими контрпримерами можно оправдывать уродство кода.
Кроме того, это зло давно уже стало паттерном.
Но за веши вроде:
int someshit() { int theData; ... int doFoo() { # делаем что-то c theData ... } ... int doBar() { # делаем еще что-то с theData ... } ... doFoo(); ... doBar(); ... return theData; }надо пороть.
Использование локальных данных внешней функи во внутренних, как раз, говорит о том, что деление кода на блоки не продумано. Чем использование данных внешней функции отличается от передачи данных через глобальную переменную?
Единственный случай, когда можно использовать данные из внешнего блока — это внутри коллбэка, да и то, только тогда, когда автор кода, зовущего коллбэк не позаботился о передаче дополнительных параметров.
Не забывайте, каждая функция должна выполнять только одно действие.