Здравствуйте, investigator, Вы писали:
I>Здравствуйте, Beam, Вы писали:
B>>В Smalltalk можно написать метод doFirst: doMiddle: doLast:, который решит эту проблему. Перебор коллекции будет осуществляться внутри этого метода, а вот сами операции, которые необходимо выполнить можно передать в качестве параметров.
I>В Java можно написать метод
I>
Да, я знаю о такой возможности. Я могу сказать одно — ЭТО НЕ УДОБНО. По следующим причинам:
1. для каждого такого метода Вам придется описать свой интерфейс (а их может быть очень много)
2. затруднено использование локальных переменных класса в котором используется этот метод, т.к.
в анонимный класс можно передавать только final переменные. Это тоже обходится (достаточно коряво)
3. все это — достаточно редко используемая техника для Java, многие будут спотыкаться при чтении этого кода, а для Smalltalk же это обычная техника
B>>На мой взгляд этот код читается легче, чем на Java. Да и возможности повторного использования у него выше.
I>Читабельность в данном случае, ИМХО, зависит только от того, на чем читатель привык писать.
Скажу за себя. Я могу написать этот код и на Java и на Smalltalk, но понятнее мне данный код Smalltalk.
Хотя бы потому что мне не нужно создавать анонимный класс.
Кстати, сушествуют и другие способы реализации аналога closures. Например, через reflection, или с помощью ввода типовых интерфейсов для описания closure (аналогично интерфейсу Runnable). Здесь появляются другие плюсы и минусы, но все равно это не удобно!
B>>Все это возможно в Smalltalk и невозможно в Java благодаря наличию блоков кода (BlockClosure).
I>Что-то, возможно, в Java и невозможно из-за отсутствия closures, но только не то, что было приведено в качестве примера.
Я имел ввиду, что в случаях, аналогичных описанному выше, на Java ИМХО невозможно написание одновременно легко читаемого и повторно используемого кода. Т.к. появляются дополнительные синтаксические конструкции, которые нужны лишь для обхода ограничений языка.
Т.е. если мы хотим легко его читать, мы уходим от этих синтаксических конструкций и, следовательно, от повторного использования. Если хотим повторное использование, то затрудняется восприятие кода.
I>Java может и подтянется (разговоры есть): I>http://gafter.blogspot.com/2006/08/closures-for-java.html I>http://gafter.blogspot.com/2006/08/whats-point-of-closures.html
К сожалению, это лишь надстройка на Java или изменение самого языка. Но этого нет в самом языке (официально).
Пока не примут стандарт, не будет поддержки — IDE, библиотек, а следовательно не будет массового использования этих фич.
С такми же успехом можно использовать уже готовые языкы для JVM. Тот же Groovy.
Здравствуйте, FDSC, Вы писали:
FDS>Давайте будем искать ошибку целый день, а в результате окажется, что в какой-то библиотечной функции не было учтено, что возврат может происходить туда-то.
. И механизм "учитывания" такой же — вставить finaly при надобности.
Кстати, в ST есть два способа реакции: ensure:, который вызывается всегда и аналог finaly, и ifCurtailed: который вызывается только если произошло исключение и аналог ловлению любого исключения, некоей обработки, и пробрасывания исключения дальше, только само исключение при этом недоступно. Удобно если нужно обработать факт сбой, а что за сбой не важно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
FDS>>Вот если бы эти лямбды нельзя было бы передавать как параметры другим методам, тогда можно было бы сказать, что это полезно и не слишком опасно для ограниченного применения.
VD>На самом деле это "фича" со своими бенефитами и своими недостатками. И их оценка не так проста. Лично я считаю, что подобные континюэйшоны могут привести к совершенно запутанному коду, так как читая его мы не рассчитываем на то, что функция может не вернуть управление или что управление из середины выражения может бесследно исчезнуть и оказаться уже в конце метода.
Я выделил ещё, вы не совсем правильно меня поняли. Я полностью с вами согласен. Но в некоторых ситуациях это было бы что-то вроде сишных макросов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, VladD2, Вы писали:
VD>>В функциональных языках return то не приветствуется, а тут вольный выход из любой точки выражения. По-моему, то чистой воды грабли.
ANS>В ST которые реализовывали для JVM и .Net ВМ нелокальный возврат реализовывали через механизм исключений. То есть, этот код эквивалентен созданию своего уникального класса исключения, определению блока try..catch, который ловит это уникальное исключение _перед_ вызовом метода с блоком, и бросанию этого исключения при активации блока. Плюс ошибка при попытке бросить исключение, если управление уже вышло из нашего уникального try..catch.
Но этот возврат происходит при ошибке, которую метод не в состоянии обработать. Исключения больше ни для чего другого не используются. А для чего используются ваши блоки?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Sinclair, Вы писали:
S>>Во-вторых, мне не нравится сам подход. Это что же, я буду изобретать по методу на каждую мыслимую транзакцию??? Имхо, лучше дать пользователю возможность явно обозначать границы:
ANS>Эти коллекции специально введены для того, чтобы не использовать синхронизацию. Я так понимаю, в C# такого не предвидится по синтаксическим причинам?
Причём тут синтаксические причины? Вас просто хотели запутать. Вы всё правильно говорили.
S>>А, ну вот это уже интереснее, хотя скорее всего читаться будет хуже, чем то же самое в виде try/catch.
ANS>Ну я пример кода привёл. Он действительно выглядит хуже чем с try/catch, но, как я указал, он неэквивалентен этому способу а лучше его (хотя бы потому, что исключение KeyNotFound может выбросить какаято внутренняя часть мапы, и эта ошибка будет замаскирована).
Ну, в таком случае сделайте throw; в конце обработки исключения, и её увидят все
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>И вот еще что... Ты ответил не на мой вопрос. Я не спрашивал на кого ориентируется мэйнстрим. Я просил привести примеры амбиций мэйнстрима. Мы ведь говорили об оскорблениях и выливаемом дерьме выливаемом с амбициозностю и пафасом. Ты заговорил об "амбициях мэйнстрима". Так будь добр предявить какие-то факты существования амбиций. Ты вообще хорошо понимаешь смысл этого слова?
ГВ>Естественно, у самого мэйнстрима, как у неодушевлённого явления, амбиций никаких нет. Я скорее говорю о тех требованиях, которые предъявляются к окружающим ради "следования майнстриму".
И что это за требования?
ГВ>>> Это натаскивание на новые API в рамках одной идеи и не более того. А ещё и перекос в сторону "специалистов по API xxxxx", специалистов "по библиотеке X". VD>>Ну, что же поделаешь если библиотеки стали сложными. И причем тут амбиции, то?
ГВ>Так в том-то и дело, что их сложность преувеличивается и ммм... подтягивается под понятие "специализация". В конце концов, любая библиотека пишется для упрощения решения определённого круга задач. Для упрощения, а не для создания группы посвящённых. В последнем случае это уже не общеизвестная библиотека, а нечто иное.
ГВ>Впрочем, возможно, что я преувеличиваю.
Не сильно
ГВ>>>Ну и кому это понравится? VD>>Хороший вопрос. Так что понравится то? Быдляческое недменность всех этих Колхозов, Вин2К и т.п.? Мне лично оно не не нравится. Мне вообще не наравится когда другие говоря со мной начинают намекать, что я или другие люди не дерьмо, а он Д'артоньян на белом коне.
ГВ>А мне не нравится, когда некто начинает вливать про "закостенелые мозги", "замшелые стереотипы" и "фобии". И почему-то я не удивляюсь, что этот же некто остро реагирует на нелицеприятные высказывания других.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2,
ГВ>Дополню рассуждения на тему опыта.
ГВ>Маленькая мышка сожрать большой амбар зерна, то есть "сделает" очень много, но банальным грызуном с примитивной моделью существования она от этого быть не перестанет. Тогда как учёный может жизнь положить на безуспешные исследования, то есть "сделать" в смысле ощутимого результата очень мало, но, возможно, проложить этим дорогу другим.
ГВ>Так что, при жизни к учёному нужно относиться пренебрежительнее, чем к грызуну?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2,
ГВ>Ты не ответил на заданный вопрос:
ГВ>
VD>>>>...относиться с уважением и к другим. Они ведь тоже что-то сделали?!
ГВ>>>Как ты думаешь, почему считается некорректным приём дискуссии, называемый "апелляцией к опыту"? Никогда не задумывался?
VD>>Задумывался. Когда ты к нему прибегал.
ГВ>Ну так почему же этот приём считается некорректным?
Он считается некорректным, потому что со сслыкой на опыт невозможно спорить по причине того, что опыт у всех разный.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, minorlogic, Вы писали:
M>>>Известно , что счет удобнее вести в 12 рмчной системе исчесления , но пользуемся мы 10 ричной ..
FDS>>Это откуда это известно. Мне вот говорили, что лучшая система исчисления — с основанием с числом e , так и не знаю почему
M>Были такие исследования, источник не помню. но вкратце таблица умножения намного проще.
M>12 делится без остатка на 2 , 3, 4, 6, в отличие от 10 который делится на 2 и 5. Помните как легко делить на 2 и на 5 различные числа в 10 ричной системе .
Тогда давайте 30-ричную 30=2*3*5 или 210-ричную 30*7
Здравствуйте, Beam, Вы писали:
B>Здравствуйте, investigator, Вы писали:
I>>Здравствуйте, Beam, Вы писали:
B>>>В Smalltalk можно написать метод doFirst: doMiddle: doLast:, который решит эту проблему. Перебор коллекции будет осуществляться внутри этого метода, а вот сами операции, которые необходимо выполнить можно передать в качестве параметров.
I>>В Java можно написать метод
I>>
B>Да, я знаю о такой возможности. Я могу сказать одно — ЭТО НЕ УДОБНО. По следующим причинам: B>1. для каждого такого метода Вам придется описать свой интерфейс (а их может быть очень много) B>2. затруднено использование локальных переменных класса в котором используется этот метод, т.к. B>в анонимный класс можно передавать только final переменные. Это тоже обходится (достаточно коряво) B>3. все это — достаточно редко используемая техника для Java, многие будут спотыкаться при чтении этого кода, а для Smalltalk же это обычная техника
Не знаю, как для Явы, а для C# — это нормально.
B>>>На мой взгляд этот код читается легче, чем на Java. Да и возможности повторного использования у него выше.
I>>Читабельность в данном случае, ИМХО, зависит только от того, на чем читатель привык писать.
B>Скажу за себя. Я могу написать этот код и на Java и на Smalltalk, но понятнее мне данный код Smalltalk. B>Хотя бы потому что мне не нужно создавать анонимный класс.
Ну, не только же Ява на свете есть.
I>>Что-то, возможно, в Java и невозможно из-за отсутствия closures, но только не то, что было приведено в качестве примера.
B>Я имел ввиду, что в случаях, аналогичных описанному выше, на Java ИМХО невозможно написание одновременно легко читаемого и повторно используемого кода. Т.к. появляются дополнительные синтаксические конструкции, которые нужны лишь для обхода ограничений языка.
B>Т.е. если мы хотим легко его читать, мы уходим от этих синтаксических конструкций и, следовательно, от повторного использования. Если хотим повторное использование, то затрудняется восприятие кода.
Не так уж оно и затрудняется: это уже действительно от привычки зависит
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, FDSC, Вы писали:
FDS>>Давайте будем искать ошибку целый день, а в результате окажется, что в какой-то библиотечной функции не было учтено, что возврат может происходить туда-то.
ANS>Всё, на эту тему отвечаю в последний раз: механизм возврата подобен механизму исключений
. И механизм "учитывания" такой же — вставить finaly при надобности.
ANS>Кстати, в ST есть два способа реакции: ensure:, который вызывается всегда и аналог finaly, и ifCurtailed: который вызывается только если произошло исключение и аналог ловлению любого исключения, некоей обработки, и пробрасывания исключения дальше, только само исключение при этом недоступно. Удобно если нужно обработать факт сбой, а что за сбой не важно.
Вы меня не поняли. Я говорю о том, что если исключение не было учтено, то это значит, что не была учтена ошибочная ситуация. А тут мы можем не учесть просто некоторое штатное поведение алгоритма. Просто то, что эта возможность используется как штатная работа является не безопасной. Тут уже сторонники SmallTalk уже несколько раз говорили про небезопасность исключений, а тут всё похуже будет.
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, Kisloid, Вы писали:
VD>>>Да, уж. Забавно, что если бы не любовь к смешиванию с дерьмом, то их (егоЭ) бы было интересно послушать.
K>>Кстати говоря да, я даже сегодня прочитал все сообщения Win2K'ея. Если фильтровать все его поливания дерьмом остальных, то он очень толковые вещи говорит, местами.
NB>если он тот, кто я думаю, то кого попало (без причины) он дерьмом не обливает.
И что, это даёт какое то моральное право обливать дерьмом?
Здравствуйте, FDSC, Вы писали:
FDS>Я уже говорил, что грабли здесь появляются из-за того, что этими блоками можно слишком легко манипулировать — в частности, передавать в другую функцию. Я даже сказал где-то, что если это запретить (их передачу в качестве параметров), то возможность довольно интересная получится.
Если Вы запретите передачу блоков в качестве параметров Вы потеряете их всю мощь.
Как я Вас понял, сомнения Ваши заключаются в том, что метод в который передан блок при выполнении передаст управление неизвестно куда.
Но сам метод никуда не передает выполнение. Он лишь выполняет блок кода, который ему указали. Т.е. методу абсолютно все равно что Вы там делаете в блоке кода — просто вычисления или передачу управления.
Давайте посмотрим на код Java и Smalltalk.
// Javaint method(){
int result;
if (a < 5){
result := 8;
} else {
result := 10;
}
return result;
}
"Smalltalk"
method
| result |
(a < 5)
ifTrue: [result := 8]
ifFalse: [result := 10].
^result
Вот код с возвратами
// Javaint method(){
int result;
if (a < 5){
return 8;
} else {
return 10;
}
}
"Smalltalk"
method
| result |
(a < 5)
ifTrue: [^8].
ifFalse: [^10].
Поведение приведенного выше кода абсолютно идентично.
Да, проблема может возникнуть, если переданный блок кода используется для вычислений, которые затем используются для работы метода.
Проведем эксперимент. Есть у класс Коллекция метод select с параметром-блоком кода. Этот метод пробегает по всей коллекции, для каждого элемента вычисляет блок, и если значение true, добавляет этот элемент в коллекцию-результат.
method
| result |
result := #(1 2 3 4 5) select: [:each | each > 3]. "результат #(4 5)"
^result size "Возврат из метода со значением 2"
Этот метод ожидает, что блок можно выполнить и получить результат. Т.е. он не предполагает, что будет из блока передано управление.
А мы вот нарушим это правило. Я так понимаю, Вы этого и опасаетесь.
При выполнении этого кода произодет выход из методоа со значением 10.
Сделаем то же самое на Java.
int method(){
ArrayList result = new ArrayList();
for (int elem=1; elem<=5; elem++) {
boolean cond = elem > 3; // специально выделил отдельную переменную - это "наш блок кода"
if (cond)
result.add(elem);
}
return result.size(); "результат 2"
}
int method(){
ArrayList result = new ArrayList();
for (int elem=1; elem<=5; elem++) {
return 10; // результат 10 - заменили старый блок кода на новый, теперь здесь уже имеется возврат из метода
if (elem > 3)
result.add(elem);
}
return result.size(); // сюда не попадем
}
Как видите, поведение кода одинаковое, передаем мы блоки в качестве параметров или нет.
А вот то, что в середине цикла написано return (что тоже самое, что в select поставить ^) — это уже логическая ошибка.
Но сами блоки кода такие ошибки не создают, ведь вы сами формируете блок, который должен быть выполнен.
Извините, если длинно написал... Это все из-за примеров.
Здравствуйте, FDSC, Вы писали:
К>>>К примеру, что будет если блок вернуть из метода? А в блоке будет возврат из этого метода (который уже завершился)?
ANS>>Ран-тайм исключение.
FDS>А ведь это можно проверить статически...
Проблема останова. Подсказка: если бы это можно было проверить статически, то программы не нужно было бы запускать
Здравствуйте, FDSC, Вы писали:
FDS>Можете дать какую-нидуь ссылку на Лисп (компилятор и, хотя бы, стандарт, а лучше книгу на русском), а то у меня от поиска в интернете крышу сносит
trophim wrote: > З.Ы. Нам в университете както преподаватель сказал: пролог лучше не учите — голову сломаете.
Это не преподаватель, это вредитель какой-то. Благодаря таким наше
образование катится известно куда. Видел вчера книгу в магазине, явно
вот такие отечественные преподаватели писали, — "Основы алгоритмизация и
программирования в среде VBA". Вы себе можете представить такого зверя:
"алгоритмизация в среде VBA"? Вот получает человек представление о
программировании на таком курсе, а рынок — нехватку квалифицированных
кадров, РСДН — рассуждения о расстоянии от мэйнстрима до нормальных
инструментов и т.д.
B>int method(){
B> ArrayList result = new ArrayList();
B> for (int elem=1; elem<=5; elem++) {
B> return 10; // результат 10 - заменили старый блок кода на новый, теперь здесь уже имеется возврат из метода
B> if (elem > 3)
B> result.add(elem);
B> }
B> return result.size(); // сюда не попадем
B>}
B>
B>Как видите, поведение кода одинаковое, передаем мы блоки в качестве параметров или нет. B>А вот то, что в середине цикла написано return (что тоже самое, что в select поставить ^) — это уже логическая ошибка. B>Но сами блоки кода такие ошибки не создают, ведь вы сами формируете блок, который должен быть выполнен.
Я сам формирую блок, и могу чего-то не учесть. А что касается выделенного мной фрагмента, то он, по крайней мере в C#, выдаст предупреждение или даже ошибку типа "недостижимый код".
B>Извините, если длинно написал... Это все из-за примеров.
Ничего, наоборот, понятнее.
Здравствуйте, RustM, Вы писали:
K>>>Кстати говоря да, я даже сегодня прочитал все сообщения Win2K'ея. Если фильтровать все его поливания дерьмом остальных, то он очень толковые вещи говорит, местами.
NB>>если он тот, кто я думаю, то кого попало (без причины) он дерьмом не обливает.
RM>И что, это даёт какое то моральное право обливать дерьмом?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, FDSC, Вы писали:
К>>>>К примеру, что будет если блок вернуть из метода? А в блоке будет возврат из этого метода (который уже завершился)?
ANS>>>Ран-тайм исключение.
FDS>>А ведь это можно проверить статически...
ANS>Проблема останова. Подсказка: если бы это можно было проверить статически, то программы не нужно было бы запускать
Это можно проверить статически. Достаточно просмотреть куда записывается блок кода. Это элементарно
