Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 159
хабракат нужен.
интересненько...
только вот не ясненько где на практике такое можно применять ? в каких случаях ?
только вот не ясненько где на практике такое можно применять ? в каких случаях ?
Судя по примерам непонятно как это можно использовать(возмоэно не удачные примеры)
Зачем лямбда фукцию оборачивать в обычныю в стандартном ее понимаии? Для чего это сделано не понятно.
Я например не вижу смысла в использовании данных конструкций в таком виде в каком они представлены в примере.
Зачем лямбда фукцию оборачивать в обычныю в стандартном ее понимаии? Для чего это сделано не понятно.
Я например не вижу смысла в использовании данных конструкций в таком виде в каком они представлены в примере.
так вот и я не вижу - зачем такие извращения создавать если это можно сделать обычными функциями...
наверное это просто неудачный пример. Подождем 5.3 или позже погуглим примеры от разработчиков и вменяемые комментарии на этот счет
Если это лучший пример из того что найду, то я не понимаю зачем такое создали в пхп 5.3 ? чтобы еще больше усложнять свой код ?
наверное это просто неудачный пример. Подождем 5.3 или позже погуглим примеры от разработчиков и вменяемые комментарии на этот счет
Если это лучший пример из того что найду, то я не понимаю зачем такое создали в пхп 5.3 ? чтобы еще больше усложнять свой код ?
class A {
var func=array();
public function _construct() {
$this->func['del']=function() {/*Some actions*/}
}
}
class A
{
public function del(...){....}
}
зачем изобретать велосипед ?:)
class A extends b,c {} - такое невозможно, а вещь довольно полезная. Но используя эту фичу, такое можно сделать реальностью.
хранить указатели на родителя и потом руками перенаправлять запросы к методам родителя ?
это изврат - хотя по сути по другому никак
лучше бы создатели пхп сделали таки множественное наследование
Чтобы динамически изменять методы класса уже давно в PHP есть удобный механизм __call. И не нужно извращаться с массивами. И клиент класса не знает о деталях реализации (в отличие от случая с массивами)
а как понимать если он вам не понадобиться ?? зачем вы его вообще в проект класса заложили тогда если он вам не понадобится ? :) мне кажется это был просто плохой пример динамически создаваемых методов.
лично по моему убеждению все методы должны быть четко определены. и не должны создаваться,удаляться в процесс работы скрипта.
лично по моему убеждению все методы должны быть четко определены. и не должны создаваться,удаляться в процесс работы скрипта.
Большинство современных языков (Java, C#) отказались от множественного наследования (оно сильно усложняет логику программы и добавляет много неоднозначностей).
Наверное, стоит добавить: от множественного наследования интерфейса и реализации одновременно. А вот по отдельности - другое дело. Множественное наследование реализации в виде mixins (как в ruby при импортировании модуля в класс) это очень неплохая штука, позволяет избежать дублирования кода в сложных ситуациях.
Иногда очень удобно передавать функцию как параметр.
Это Вам позволит, например, создать массив функций, динамически добавлять и удалять их из массива, вызывать в зависимости от ситуации: $funcArray[i]($data)
Итп... в общем можно будет провести аналогию с JavaScript'ом.
Это Вам позволит, например, создать массив функций, динамически добавлять и удалять их из массива, вызывать в зависимости от ситуации: $funcArray[i]($data)
Итп... в общем можно будет провести аналогию с JavaScript'ом.
а можно пример когда удобнее передавать функцию как параметр ?
очень хотелось бы в идеале иметь два примера.
1. когда функция как параметр
2. тоже самое только параметры не функция
был бы очень благодарен
очень хотелось бы в идеале иметь два примера.
1. когда функция как параметр
2. тоже самое только параметры не функция
был бы очень благодарен
например, правило сравнения при сортировки элемнтов массива
preg_replace_callback ;)
Без callback'а вообще невозможно будет что-то сотворить...
Без callback'а вообще невозможно будет что-то сотворить...
Лично я использовал это для валидации форм. Есть универсальный класс валидации, который вызывает функцию, которую ему передают. А передать я ему могу функцию для проверки числа, даты и тп.
Вообще ситуации разные бывают. Например Вы хотите вызвать функцию, чтобы в результате выполнения возникло событие:
GetSomeData($someConnectionInfo, OnDataGot);
Вообще ситуаций много разных, щас туго соображаю, в голову не лезут. Но если Вы писали на яваскрипте, Вы поймёте.
Вообще ситуации разные бывают. Например Вы хотите вызвать функцию, чтобы в результате выполнения возникло событие:
GetSomeData($someConnectionInfo, OnDataGot);
Вообще ситуаций много разных, щас туго соображаю, в голову не лезут. Но если Вы писали на яваскрипте, Вы поймёте.
Мне кажется этого вполне хватает.
function hello($s) { echo 'Hello '.$s.'!'; }
$f='hello';
$f('world');
function hello($s) { echo 'Hello '.$s.'!'; }
$f='hello';
$f('world');
Functional-style(array_map, array_filter, etc) операции над массивами станут значительно удобнее использовать. В нынешней форме они феерически уродливы. Передавать название функции вместо объекта или хотя бы ссылки - кошмар.
Хотя, все это все равно выглядит костылями.
Хотя, все это все равно выглядит костылями.
А чем create_function не устраивает? Я использую ее в подобных функциях. Правда код в строке писать не удобно. Но если код не большой, то это лучше чем заводить новую функцию
Ну вообще говоря, create_function это ужасный хак. Она создаёт функцию со случайным именем в глобальной области видимости, что не есть хорошо. К тому же, эта функция не может замыкаться на контекст (как в предлагаемом патче), в результате дополнительные параметры в неё очень проблематично передать, только как глобальные данные. Насчёт нежелания заводить новую функцию - так и не надо. Просто в примерах этого нет, но функцию можно будет написать прямо вместо параметра (так же как при create_function).
как-то не очень красиво оно выглядит :( в том же python и ruby оно логичнее получается.
Погуглил, нашел прикол:
"Можно ли будет, познав лямда-функции C++ считать себя папой функциональщины? Что б не было как с сиплюсплюсным ООП который, к примеру, смоллтолкисты вообще таковым не считают. Вопрос чисто религиозный :)"
"Можно ли будет, познав лямда-функции C++ считать себя папой функциональщины? Что б не было как с сиплюсплюсным ООП который, к примеру, смоллтолкисты вообще таковым не считают. Вопрос чисто религиозный :)"
Тем не менЕе.
Э-э-э-э, что-то я не понял это предложение:
"В ходе дискуссии в списку рассылки, было принято решение , что без поддержки замыканий, нет необходимости в добавить их в PHP"
Это переводчик так намудрил?
"В ходе дискуссии в списку рассылки, было принято решение , что без поддержки замыканий, нет необходимости в добавить их в PHP"
Это переводчик так намудрил?
В php только раз желание появлялось воспользоваться лямбда. Они там такие убогие.
А вот в ECMAScript использую постоянно, очень удобно!
А вот в ECMAScript использую постоянно, очень удобно!
http://wiki.php.net/rfc/closures
вот тут расписано куда более понятно как и зачем будут лямбда функции и замыкания работать в пхп
вот тут расписано куда более понятно как и зачем будут лямбда функции и замыкания работать в пхп
Не поделитесь, зачем вам множественное наследование в PHP?
Каша какая-то.
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
Да - таки "зло".
При использовании множественного наследования возникает целая куча спорных ситуаций. Таких например как "какой метод одного из родителей использовать, если в обоих родительских классах есть методы с одинаковыми названиями?"
далее. если Вам необходим доступ к методам двух "родителей", то возможно Вам нужно делегирование объектов, а не множественное наследование?
Желание работать с множественным наследованием возникает из-за непонимания сути ООП, из-за мыслей что "это круто!!!" и из-за недостаточного опыта разработки...
Поверьте - многие из тех, кто ощутил прелесть множественного наследования, сожалеют что оно есть. Сам же я на практике множественное наследование не возжелал ни разу, а проекты, поверьте, выходят далеко за грани форумов и гостевых книг ;) :)
При использовании множественного наследования возникает целая куча спорных ситуаций. Таких например как "какой метод одного из родителей использовать, если в обоих родительских классах есть методы с одинаковыми названиями?"
далее. если Вам необходим доступ к методам двух "родителей", то возможно Вам нужно делегирование объектов, а не множественное наследование?
Желание работать с множественным наследованием возникает из-за непонимания сути ООП, из-за мыслей что "это круто!!!" и из-за недостаточного опыта разработки...
Поверьте - многие из тех, кто ощутил прелесть множественного наследования, сожалеют что оно есть. Сам же я на практике множественное наследование не возжелал ни разу, а проекты, поверьте, выходят далеко за грани форумов и гостевых книг ;) :)
нет - ACL не зло. Но реализовывать его множественным наследованием.. гы. по меньшей мере странно.
Вы впадаете в крайности. Умение управлять сложностью не менее важно чем уметь программить в принципе. Код должен быть изначально понятен человеку, а уже потом машине.
Суть ООП в том, что бы представлять структуры в более логическом и взаимосвязанном виде (не путать со связностью).
Верю. Вы программите долго. Вы даже старше меня. Но даже если это и так - это не означает что опыта у Вас больше. Да - таков парадокс...
Да что Вы к этим минусам? ))) Меня так же загнали - я ж не плачу...
Вы впадаете в крайности. Умение управлять сложностью не менее важно чем уметь программить в принципе. Код должен быть изначально понятен человеку, а уже потом машине.
Суть ООП в том, что бы представлять структуры в более логическом и взаимосвязанном виде (не путать со связностью).
Верю. Вы программите долго. Вы даже старше меня. Но даже если это и так - это не означает что опыта у Вас больше. Да - таков парадокс...
Да что Вы к этим минусам? ))) Меня так же загнали - я ж не плачу...
> Вы даже старше меня.
Улыбнуло))
ЗЫ. Для ленивых: creOtiv и AlexeyTokar - одногодки ;-)
Улыбнуло))
ЗЫ. Для ленивых: creOtiv и AlexeyTokar - одногодки ;-)
А, простите, в каком банке Вы работаете? Или для какого банка пишете?
> И с какой это башеи зеленой вы взяли что вы програмите лучше меня? Вы видели как я пишу?
Я думаю, достаточно полистать ваш ЖЖ, чтобы определить уровень вашей подкованности. А банк... банку только минус за экономию денег на ИТ-отделе.
Я думаю, достаточно полистать ваш ЖЖ, чтобы определить уровень вашей подкованности. А банк... банку только минус за экономию денег на ИТ-отделе.
Фи как некрасиво) смарти зло))
Не всегда шаблоны будете сами писать. Бывает, что этим занимаются сторонние люди, которым легче выучить синтаксис smarty, который в свою очередь похож на кучу других шаблонизаторов, так что схавается легче. Плюс смарти расширяем...
не вижу извращения. смарти код гораздо чище => понятнее для понимания.
А зачем ему учить пхп? Разница, скажем так, в объёме материала для изучения. Мануал смарти маленький и понятный.
А зачем ему учить пхп? Разница, скажем так, в объёме материала для изучения. Мануал смарти маленький и понятный.
Видимо имеется ввиду тот момент, что:
1. ПХП изначально предназначался в качестве "клея" между данными и представлением.
1. смарти использует свой язык, так сказать получилось "еще одно ПХП, написанное на ПХП".
1. ПХП изначально предназначался в качестве "клея" между данными и представлением.
1. смарти использует свой язык, так сказать получилось "еще одно ПХП, написанное на ПХП".
1. само название PHP уже давно не означает personal home page, так что чем там пхп изначально задумывался не имеет значения
2. согласен, но лично Вам не кажется, что {$var} смотрится гораздо лучше (или какой-то там сокращенный синтаксис был, точно не помню никогда не использовал - кажется такой)
А если посмотреть на условия
условие1
условие2
вместо
{if $var}
условие1
{else}
условие2
{/if}
2. согласен, но лично Вам не кажется, что {$var} смотрится гораздо лучше (или какой-то там сокращенный синтаксис был, точно не помню никогда не использовал - кажется такой)
А если посмотреть на условия
условие1
условие2
вместо
{if $var}
условие1
{else}
условие2
{/if}
Функционал смарти меньше? Чем это он меньше? Примеры в студию (на пастбин). Смарти чище. Спросите свою подругу, что ей приятнее для глаза.
>Вот как вы например на смарти реализуете >рекурсию?
Давайте конкретную задачу. Если вы про создание и вызов функции, которая, в свою очередь, будет запускать себя же, то я просто напишу плагин для смарти.
>Я на смарти писал под Koobi, гавно полное.. >то что на пхп я напишу в две строки на >гребаном смарти у меня выходит дохрена. Так >в чем сдесь чистота?
Давайте уже примеры, а? А то всё слюной брызжите, а примеров нет. Вот спокойненько сядьте и накидайте на pastebin.ru примеров того, где смарти просасывает.
>А для дизайнера что смарти, что пхп одного >поля ягоды.
Сколько дизайнеров лично Вы уже подсадили на php?
>А если вы еще и будете юзать все настройки >которые есть у смарти, а это обязательно >если не хотите неплохих лагов, то вы сразу >уразумите что такое чище.
Еще раз - давайте примеры. Я уже больше года использую смарти и ни разу не сел в лужу. На смарти даже реализовать можно активные шаблоны, так что не надо тут про сложность и не замыкайтесь в собственном незнании и неумении.
>А мануал смарти в 2 тома книги по 600стр >это мало??
Это что такое? Я про мануал, какие тома?!
php_manual_ru.chm - 7 Мб
Smarty-2.6.7-docs.chm - 270 Кб
Разница есть?
>Как по мне то лучше потратить время на >изучение языка програминга чем на непонятно >что.
Ваше право, Вы программист и срать вы хотели на других людей, которым, возможно, придётся менять Ваши шаблоны. И не дай бог им оказаться не программистами на php.
>Вот как вы например на смарти реализуете >рекурсию?
Давайте конкретную задачу. Если вы про создание и вызов функции, которая, в свою очередь, будет запускать себя же, то я просто напишу плагин для смарти.
>Я на смарти писал под Koobi, гавно полное.. >то что на пхп я напишу в две строки на >гребаном смарти у меня выходит дохрена. Так >в чем сдесь чистота?
Давайте уже примеры, а? А то всё слюной брызжите, а примеров нет. Вот спокойненько сядьте и накидайте на pastebin.ru примеров того, где смарти просасывает.
>А для дизайнера что смарти, что пхп одного >поля ягоды.
Сколько дизайнеров лично Вы уже подсадили на php?
>А если вы еще и будете юзать все настройки >которые есть у смарти, а это обязательно >если не хотите неплохих лагов, то вы сразу >уразумите что такое чище.
Еще раз - давайте примеры. Я уже больше года использую смарти и ни разу не сел в лужу. На смарти даже реализовать можно активные шаблоны, так что не надо тут про сложность и не замыкайтесь в собственном незнании и неумении.
>А мануал смарти в 2 тома книги по 600стр >это мало??
Это что такое? Я про мануал, какие тома?!
php_manual_ru.chm - 7 Мб
Smarty-2.6.7-docs.chm - 270 Кб
Разница есть?
>Как по мне то лучше потратить время на >изучение языка програминга чем на непонятно >что.
Ваше право, Вы программист и срать вы хотели на других людей, которым, возможно, придётся менять Ваши шаблоны. И не дай бог им оказаться не программистами на php.
ладно. показываю для особо крутых программистов как выглядит вывод дерева, который хранится как список смежностей (adjacency list)
{include file="menu/view.tpl" items=$menu->getItems()}
содержимое view.tpl:
{foreach from=$items key="id" item="item"}
{$item->getTitle()}
{if sizeof($item->getChildrens())}{include file="menu/adminview.tpl" items=$item->getChildrens()}{/if}
{/foreach}
Вот Вам и рекурсия. И верстальщику лезть не надо никуда.
Теперь давайте Ваш вариант того же. Потягаемся.
>Реализуйте на смарти дерево с N-им порядком))
adjacency уже показал. Вывод дерева на NS могу показать только после Вашего контр-примера с adjacency, а то складывается впечатление, что спор веду с позером.
p.s. по поводу тормознутости - система кэширования и компилируемые шаблоны спасают, но то, что это дополнительная нагрузка - с этим согласен.
{include file="menu/view.tpl" items=$menu->getItems()}
содержимое view.tpl:
{foreach from=$items key="id" item="item"}
{$item->getTitle()}
{if sizeof($item->getChildrens())}{include file="menu/adminview.tpl" items=$item->getChildrens()}{/if}
{/foreach}
Вот Вам и рекурсия. И верстальщику лезть не надо никуда.
Теперь давайте Ваш вариант того же. Потягаемся.
>Реализуйте на смарти дерево с N-им порядком))
adjacency уже показал. Вывод дерева на NS могу показать только после Вашего контр-примера с adjacency, а то складывается впечатление, что спор веду с позером.
p.s. по поводу тормознутости - система кэширования и компилируемые шаблоны спасают, но то, что это дополнительная нагрузка - с этим согласен.
ну а я по-вашему молодым специалистом небыл? :)
почему бы не смотреть на pctools.com или magentocommerce.com, м?
почему бы не смотреть на pctools.com или magentocommerce.com, м?
Я согласен с Алексеем, надо грамотно и без фанатизма пользоваться.
И не кричать фреймворки - круто, множественная наследственность тоже круто...
Нужно спокойно и размеренно, анализируя архитектуру, применять нужное решение.
Как пользоваться инструментарием - дело самого разработчика. Чем больше вы усложняете "систему" - тем больше вероятность встречи глюка, бага. Я считаю наоборот - надо "систему(разработку)" как можно более упрощать, унифицировать и т.п.
И не кричать фреймворки - круто, множественная наследственность тоже круто...
Нужно спокойно и размеренно, анализируя архитектуру, применять нужное решение.
Как пользоваться инструментарием - дело самого разработчика. Чем больше вы усложняете "систему" - тем больше вероятность встречи глюка, бага. Я считаю наоборот - надо "систему(разработку)" как можно более упрощать, унифицировать и т.п.
какой-то хреновый у вас acl. каждая группа пользователя это отдельный класс? про сущности вообще что-нибудь слышали?
Вы приведите нормальный пример, когда использование множественного наследования действительно необходимо? Хотя лично я считаю, что это дело вкуса, но ведь не зря же во многих языках убрали множественное наследование?
Вы приведите нормальный пример, когда использование множественного наследования действительно необходимо? Хотя лично я считаю, что это дело вкуса, но ведь не зря же во многих языках убрали множественное наследование?
я могу поделиться примером из жизни (если можно реализовать более красиво, то буду признателен):
есть класс UserSession (класс работы с сессиями, авторизацией и т.п.), есть класс UserSettings (личные настройки пользователя на сайте), и такие классы с отдельной логикой могут появляться в дальнейшем.
Поэтому мне кажется удобным в этом случае использовать множественное наследование, когда я могу получить доступ к любой функции перечисленных выше классов через класс User (как точка доступа ко всем классам, касающимся пользователя).
Разве это не удобно?
есть класс UserSession (класс работы с сессиями, авторизацией и т.п.), есть класс UserSettings (личные настройки пользователя на сайте), и такие классы с отдельной логикой могут появляться в дальнейшем.
Поэтому мне кажется удобным в этом случае использовать множественное наследование, когда я могу получить доступ к любой функции перечисленных выше классов через класс User (как точка доступа ко всем классам, касающимся пользователя).
Разве это не удобно?
О том, почему такого нельзя делать, исписано множество книг по ООП. Наследование (открытое) должно обозначать связь типа "является". Т.е. в вашем случае "User является (подвидом) UserSettings), что неверно. Причин, по которым нельзя в этом случае использовать наследование много. Самая простая - увеличивается связность классов между собой. Впоследствии не получится изменить способ работы с настройками пользователя - он будет жёстко привязан к интерфейсу вашего класса UserSettings, а сессии - к классу UserSession. В этом нет ничего плохого на этапе первоначальной разработки, но если потом пытаться улучшать или модифицировать этот код - проще будет написать новый :)
спасибо за ответ, но я не понял :)
Мне кажется, что множественное наследование не поддерживается php, java, C# не по причинам того, что его плохо применяют, и от этого ухудшается отслеживание кода. Т.е. если классы от которых происходит множественное наследование могут иметь общего родителя (где-то далеко) или т.п. - могут возникнуть разные косяки... Но если классы находятся в перпендикулярных плоскостях, то я не вижу чем плохо множественное наследование. Я в своем примере использую совершенно несвязанные по логике классы (настройки, сессии и т.п.). А класс User является просто точкой "входа". Т.е. класс User не имеет собственных методов и классов. И для того, чтобы мне что-то поменять, мне нужно всего лишь поменять один из классов родителей.
Мне кажется тут уместно использование множественного наследования, разве нет?
Мне кажется, что множественное наследование не поддерживается php, java, C# не по причинам того, что его плохо применяют, и от этого ухудшается отслеживание кода. Т.е. если классы от которых происходит множественное наследование могут иметь общего родителя (где-то далеко) или т.п. - могут возникнуть разные косяки... Но если классы находятся в перпендикулярных плоскостях, то я не вижу чем плохо множественное наследование. Я в своем примере использую совершенно несвязанные по логике классы (настройки, сессии и т.п.). А класс User является просто точкой "входа". Т.е. класс User не имеет собственных методов и классов. И для того, чтобы мне что-то поменять, мне нужно всего лишь поменять один из классов родителей.
Мне кажется тут уместно использование множественного наследования, разве нет?
Наследование "ромбом" в основном имеет проблемы в компилируемых языках, потому что приходится вводить для него много частных случаев общих в остальном принципов.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
Вообще-то в Вашем случае, по-хорошему, стоит делегировать два объекта (от USettings и USession) в класс User (сделать свойствами, к примеру), но никак не наследовать от этих классов
ну в сущности я и сделал делегирование. класс User имеет свойства, в которых экземпляры классов USettings и USession, но ведь глобально это просто способ реализовать множественное наследование (из-за того, что его нет).
Глобально, вам выше пытались сказать, что это разные вещи :)
Возможно пример с пользователем не так нагляден, попробую привести другой. Если есть класс ноги и руки, то класс человека не является производным от них.
Возможно пример с пользователем не так нагляден, попробую привести другой. Если есть класс ноги и руки, то класс человека не является производным от них.
Было бы крайне забавно узнать, как относятся ламбды и замыкания к реализации множественного наследования.
всё это конечно прекрасно, но замыкания позволяют писать адски трудные для понимания костыли :)
Так мы придем к perl в котором один "профессионал" может написать код который не поймет ни один другой "профессионал" :)
Так мы придем к perl в котором один "профессионал" может написать код который не поймет ни один другой "профессионал" :)
ещё один метод суицида для гавнокодеров. я уже в ужасе от перспективы править подобный код. а сам в ближайшее время буду использовать сиё только в спорах о крутости языка.
множественное наследование - ЗЛО
анонимные функции - ЗЛО
по-моему самое полезное из того, что стоит ждать в 5.3 - LSB
анонимные функции - ЗЛО
по-моему самое полезное из того, что стоит ждать в 5.3 - LSB
кстати...
замыкание - ЗЛО :)
без него можно вполне обойтись, используя грамотную архитектуру классов
замыкание - ЗЛО :)
без него можно вполне обойтись, используя грамотную архитектуру классов
на actionscript благодаря анонимным функциям и замыканиям количество методов в классе уменьшается ровно вдвое, не говоря уже про читабельность
в яве вовсю используются объектные аналоги анонимных функций - анонимные классы
в яве вовсю используются объектные аналоги анонимных функций - анонимные классы
Мой вам совет: не высказывайте подобных мыслей в присутствии Ruby-стов. Засмеют :)
Да и вообще можно обойтись не только без замыканий но и без ООП, без языков высокого уровня и даже без компьютера! :) Зачем это все? И вообще, считать надо в уме. На свежем воздухе :)
Да и вообще можно обойтись не только без замыканий но и без ООП, без языков высокого уровня и даже без компьютера! :) Зачем это все? И вообще, считать надо в уме. На свежем воздухе :)
scala и Erlang просто пронизаные анонимными функциями, и злом их подавно никто не считает
зы Скала может стать преемником явы
ззы про эрланг итак все знают
зы Скала может стать преемником явы
ззы про эрланг итак все знают
использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение.
гениально !
так и запишу
мартину одерски, гостлингу и другим уже сел писать письмо - дескать, мужики то и не знали
так и запишу
мартину одерски, гостлингу и другим уже сел писать письмо - дескать, мужики то и не знали
вы это скажите в rsdn.declarative
Да не трогайте вы его) Человек всю жизнь на PHP пишет, а вы ему скалкой и эрлангом тыкаете. Кложеры будут до PHP доходить как и ООП - пару лет минимум.
Прежде чем делать какие-либо заявления, нужно быть в них уверенным.
А Вы попросту пытаетесь умничать
А Вы попросту пытаетесь умничать
а что тут доказывать ? что кетчуп не зеленый ? элементы функционального программирования есть/вводятся во все более-менее основные языки программирования, фп имеет под собой мощную математическую базу, На декларативных языках очень многое пишется быстрее и короче; во многих случаях реализуется такое, что империативным путем не реализуется впринципе
И тут некто заявляет(без каких-либо аргументов, что самое важное), что это фп - зло. Это просто несерьезно
И тут некто заявляет(без каких-либо аргументов, что самое важное), что это фп - зло. Это просто несерьезно
Нужно быть не уверенным в заявлениях, а как минимум разбираться в вопросе. Или хотя бы прислушиваться к тому, что люди говорят. А уверенность без понимания сути — это, уж простите, ламерством называлось всегда.
Нужно не прислушиваться к тому, что говорят люди, а САМОМУ проверять и делать выводы.
В противном случае мы превратимся в стадо овец, которых ведет один пастух
В противном случае мы превратимся в стадо овец, которых ведет один пастух
Вот и прислушайтесь. Вам уже несколько человек намекнули, что ваша позиция, мягко говоря, несостоятельная. На что им щедро «te;кто-то» наставил минусов, да и карму уменьшил. Хотя беседа вполне мирная. Вы еще не привели ни одного веского аргумента против замыканий. У меня складывается впечатление, что говорите вы это либо просто по наслышке, либо пытались применить инструмент не по назначению. Непременно, микроскопом забивать гвозди менее удобно, нежели молотком. А вот как объяснить человеку, пробовавшему микроскоп в этом качестве и уверенному, что «микроскоп — это полная чушь»... как ему объяснить, что микроскоп создавался несколько для других целей?
Замыкания и лямбда функции — это замечательный инструмент, который в умелых руках, позволяет добиваться потрясающей эффективности, лаконичности и понятности кода. Притом что количество ошибок снижается на порядок.
Эта идея является центральной в таких языках как Lisp, Erlang. В Ruby замыкания применяются практически везде. Благодаря этому, можно написать одну строку, которая была бы эквивалентна десятку строк на императивном языке, тем не менее, оставаясь абсолютно прозрачной и читаемой.
Я почти уверен в том, что ни одного из вышеперечисленных языков вы не знаете. Особенно это касается Ruby. Если бы вы поняли этот язык, то фразы типа «использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение», вы воспринимали бы не иначе как бред. Я мог бы привести соответствующие куски кода, вот только боюсь что вас они не впечатлят (как впрочем и все остальное по этой теме).
Простите, но на «пастуха» вы никак не тянете.
Замыкания и лямбда функции — это замечательный инструмент, который в умелых руках, позволяет добиваться потрясающей эффективности, лаконичности и понятности кода. Притом что количество ошибок снижается на порядок.
Эта идея является центральной в таких языках как Lisp, Erlang. В Ruby замыкания применяются практически везде. Благодаря этому, можно написать одну строку, которая была бы эквивалентна десятку строк на императивном языке, тем не менее, оставаясь абсолютно прозрачной и читаемой.
Я почти уверен в том, что ни одного из вышеперечисленных языков вы не знаете. Особенно это касается Ruby. Если бы вы поняли этот язык, то фразы типа «использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение», вы воспринимали бы не иначе как бред. Я мог бы привести соответствующие куски кода, вот только боюсь что вас они не впечатлят (как впрочем и все остальное по этой теме).
Простите, но на «пастуха» вы никак не тянете.
=)) Поподробней с этого места, если можно. Вы, вообще, знакомы с функциональным программированием?
естественно. и именно из-за знакомство с ним, предпочитаю императивное и объектно-ориентированное программирование ;)
Я тоже знаком и с императивным стилем (и с функциональным; я, вообще, больше JavaScript-программист, хоть и занимаюсь PHP на серверной стороне), и с ООП-парадигмой =) Мне просто интересно, - конкретная аргументация есть вот на это:
> использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение
и на это:
> замыкание - ЗЛО :)
Может пример приведете?
Я могу конкретный пример привести, когда анонимная функция - это "зло", но это "зло" занимает лишь 5% от мощи замыканий и анонимных функций.
> использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение
и на это:
> замыкание - ЗЛО :)
Может пример приведете?
Я могу конкретный пример привести, когда анонимная функция - это "зло", но это "зло" занимает лишь 5% от мощи замыканий и анонимных функций.
конкретная аргументация.
В мире, в котором живу я (не будем говорить что Вы сейчас в топике о РНР - это не к месту), базовая логическая структура разработки - функция. Именно на функциях основывается логический смысл программы. Именно функция имеет вполне конкретную, достаточную и четкую логику и границу. Именно функции представляет из себя кирпичики из которых в последствии (при взаимодействии через операторы) должно получиться то, что Вы возможно называете ПО, которое имеет вполне конкретную бизнес-логику.
насчет "замыкание - ЗЛО":
порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
Если в Ваших проектах есть те, что покрывают более нескольких десятков тысяч строк - Вы возможно меня поймете.
Вообще против ФП как парадигдмы я ничего не имею, но из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций, а так же повсеместные рекурсии, для себя я его не рассматриваю как "идею будущего".
В мире, в котором живу я (не будем говорить что Вы сейчас в топике о РНР - это не к месту), базовая логическая структура разработки - функция. Именно на функциях основывается логический смысл программы. Именно функция имеет вполне конкретную, достаточную и четкую логику и границу. Именно функции представляет из себя кирпичики из которых в последствии (при взаимодействии через операторы) должно получиться то, что Вы возможно называете ПО, которое имеет вполне конкретную бизнес-логику.
насчет "замыкание - ЗЛО":
порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
Если в Ваших проектах есть те, что покрывают более нескольких десятков тысяч строк - Вы возможно меня поймете.
Вообще против ФП как парадигдмы я ничего не имею, но из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций, а так же повсеместные рекурсии, для себя я его не рассматриваю как "идею будущего".
«из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций»
Опять же, обратитесь к Ruby.
Опять же, обратитесь к Ruby.
Ну, первый абзац, простите, ни о чем (простая демагогия, придание воды).
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)
> Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
То есть, вы говорите, что тот же clisp для двух (fn (a b) (+ a b)) в разных участках кода сгенерит ДВА РАЗНЫХ куска кода? ;-)
То есть, вы говорите, что тот же clisp для двух (fn (a b) (+ a b)) в разных участках кода сгенерит ДВА РАЗНЫХ куска кода? ;-)
неа, я с clisp'ом близко не знаком, я говорил в основном о циклических конструкциях (в примере JavaScript):
1. ссылка всегда на одну функцию
объект.fn = function () {alert(1);};
for (var k = 0; k < 100; k++) {
blaBla = объект.fn;
}
2. тот же случай, но 100 разных "одинаковых" функций:
for (var k = 0; k < 100; k++) {
blaBla = function () {alert(1);};
}
На этом, собственно, 5% "зла" анонимных функций, о которых я отмечал человеку, ставящему всем минусы, заканчиваются.
1. ссылка всегда на одну функцию
объект.fn = function () {alert(1);};
for (var k = 0; k < 100; k++) {
blaBla = объект.fn;
}
2. тот же случай, но 100 разных "одинаковых" функций:
for (var k = 0; k < 100; k++) {
blaBla = function () {alert(1);};
}
На этом, собственно, 5% "зла" анонимных функций, о которых я отмечал человеку, ставящему всем минусы, заканчиваются.
В таком случае ООП - не меньшее зло чем анонимные функции ;-)
> В таком случае
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
Замените
for (var k = 0; k < 100; k++) {
blaBla = function () {alert(1);};
}
на
for (var k = 0; k < 100; k++) {
blaBla = new Foo();
}
и скажите, что с точки зрения ресурсоемкости (точнее, ресурсопрожорливости) поменялось.
> ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов
А вот тут вы заблуждаетесь ;-)
for (var k = 0; k < 100; k++) {
blaBla = function () {alert(1);};
}
на
for (var k = 0; k < 100; k++) {
blaBla = new Foo();
}
и скажите, что с точки зрения ресурсоемкости (точнее, ресурсопрожорливости) поменялось.
> ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов
А вот тут вы заблуждаетесь ;-)
> и скажите, что с точки зрения ресурсоемкости (точнее, ресурсопрожорливости) поменялось.
=) ничего не поменялось, посмотрите разделы "11.2.5 Function Expressions", "13. Function Definition", "15.3 Function Objects" спецификации ECMAScript-262-3
> А вот тут вы заблуждаетесь ;-)
неа =) но все же спрошу - а где? =)
=) ничего не поменялось, посмотрите разделы "11.2.5 Function Expressions", "13. Function Definition", "15.3 Function Objects" спецификации ECMAScript-262-3
> А вот тут вы заблуждаетесь ;-)
неа =) но все же спрошу - а где? =)
> ничего не поменялось
что и требовалось доказать для фразы "ООП - зло"))
Касательно анонимных функций и случая со 100 копиями функции.
Если рассуждать логически, компилятор, вместо генерации 100 копий анонимной функции можно использовать ссылку на одну и ту же функцию, до тех пор, пока это возможно (т.е. пока вы не решите, эм.. модифицировать тело функции ;-). В этом, разумеется, _частном случае_ затраты на оставшиеся 99 функций будут близки к нулю. Исключение из этого - необходимость хранение контекста функции, но это несколько иной случай ;-)
что и требовалось доказать для фразы "ООП - зло"))
Касательно анонимных функций и случая со 100 копиями функции.
Если рассуждать логически, компилятор, вместо генерации 100 копий анонимной функции можно использовать ссылку на одну и ту же функцию, до тех пор, пока это возможно (т.е. пока вы не решите, эм.. модифицировать тело функции ;-). В этом, разумеется, _частном случае_ затраты на оставшиеся 99 функций будут близки к нулю. Исключение из этого - необходимость хранение контекста функции, но это несколько иной случай ;-)
>> ничего не поменялось
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
ай-яй-яй.. Прошу меня извинить, я привел самый неудачный пример из всех, из которых можно было бы привести (с циклами; но это касается только JS, а не анонимных функций в целом).
Более подходящим примером может быть создание объекта по событию (по клику на кнопку, например) - и если там есть присвоение:
obj.onclick = function () {};
вместо:
obj.onclick = ранееОбъявленныйХэндлер;
то при первой реализации в случае 100 созданий, будет 100 функций (во втором одна).
Или же, возвращаясь к циклу - если подобная конструкция:
var test = {};
test[0] = {};
test[0].fn = function () {};
test[1] = {};
test[1].fn = function () {};
могла бы быть построена в цикле, то здесь видно четко, что функции созданы разные:
alert(test[0].fn === test[1].fn);
Более подходящим примером может быть создание объекта по событию (по клику на кнопку, например) - и если там есть присвоение:
obj.onclick = function () {};
вместо:
obj.onclick = ранееОбъявленныйХэндлер;
то при первой реализации в случае 100 созданий, будет 100 функций (во втором одна).
Или же, возвращаясь к циклу - если подобная конструкция:
var test = {};
test[0] = {};
test[0].fn = function () {};
test[1] = {};
test[1].fn = function () {};
могла бы быть построена в цикле, то здесь видно четко, что функции созданы разные:
alert(test[0].fn === test[1].fn);
> порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
В таком случае, ООП не меньшее зло - ибо разницы между штампованием объектов и штампованием анонимных функций нет.
В таком случае, ООП не меньшее зло - ибо разницы между штампованием объектов и штампованием анонимных функций нет.
Ну как же?
Объект инкапсулирует поведение внутри себя (точнее этим класс занимается), а анонимная функция, одинаковой логики в двух местах полностью повторяет свой код, что непременно ведет к усложнению.
Это конечно если анонимные функции использовать по назначению, а не просто присваивать их переменной как показано выше, что совершенно противоречит ФП, о котором автор ведет речь, и в котором состояние системы в момент времени отсутствует по определению
Объект инкапсулирует поведение внутри себя (точнее этим класс занимается), а анонимная функция, одинаковой логики в двух местах полностью повторяет свой код, что непременно ведет к усложнению.
Это конечно если анонимные функции использовать по назначению, а не просто присваивать их переменной как показано выше, что совершенно противоречит ФП, о котором автор ведет речь, и в котором состояние системы в момент времени отсутствует по определению
> что совершенно противоречит ФП, о котором автор ведет речь
Демагогия и глупая подмена понятий, не более. Речь в примере не о ФП, а лишь об анонимной функции.
Еще раз, человек, если вы не понимаете что-то, то это не значит, что это плохо.
P.S.: небось руки уже снова чешутся кнопочку "минус" всем нажать? =))
Демагогия и глупая подмена понятий, не более. Речь в примере не о ФП, а лишь об анонимной функции.
Еще раз, человек, если вы не понимаете что-то, то это не значит, что это плохо.
P.S.: небось руки уже снова чешутся кнопочку "минус" всем нажать? =))
А в ассемблере вся логика строится на goto (jmp).
товарищу, который ставит минус - аргументируйте, не стесняйтесь
сообщество с удовольствием посмотрик, как вы перепишите без фп, скажем, амазоновские сервисы для нагруженных приложений, ну или простейший примерчик lazy evoluation сделает,,, хотя сгодится и пара-тройка миллионов потоков, запущенных на одной машине
сообщество с удовольствием посмотрик, как вы перепишите без фп, скажем, амазоновские сервисы для нагруженных приложений, ну или простейший примерчик lazy evoluation сделает,,, хотя сгодится и пара-тройка миллионов потоков, запущенных на одной машине
скала слишком сложная, чтобы стать преемником, у groovy-то больше шансов.
ммм,,, груви тормозит вследствие динамической типизации - врядли на критическиех задачах будут его использовать, в этой области у скалы преимущество
хотя мне, и то, и другое по душе - главное, чтобы было к месту
хотя мне, и то, и другое по душе - главное, чтобы было к месту
да, скорость - не самое сильное место groovy, но в 1.6 они уже значительно прибавили, а если в java7 сделают invokedynamic то жить станет ещё проще :) кстати замыканию вполне могут попасть в java7.
я был бы очень рад, если б groovy стал третьим включённым в jvm языком, наряду с java и javaFX.
я был бы очень рад, если б groovy стал третьим включённым в jvm языком, наряду с java и javaFX.
Второй язык на данный момент лежит в javax.script - реализация JavaScript под названием Mozilla Rhino. JavaFX ещё не включён да и вообще пока что больше мертворожденного напоминает, особенно после ухода Ганса Мюллера в Адоб. Invokedynamic далеко не панацея для динамических языков. Я лично очень жду когда реализуют в Rhino четвёртую спеку ES.
Про рино я в курсе, но он всё-таки скриптовый язык, чистый классна нём так просто не напишешь, насколько я понимаю, в отличии от groovy.
JavaFX в update 10 должен войти. GraphicsBuilder из groovy умеет многие фичи из JavaFX.
JavaFX в update 10 должен войти. GraphicsBuilder из groovy умеет многие фичи из JavaFX.
Хм... А Groovy не скриптовой что-ли? Rhino используется очень активно в Google, они кстати и будут основные коммитеры 4 версии. А она по функционалу очень крутая - не уступает Ruby & Python, а самое главное там будет в отличие от них опциональное статическое типизирование. Ну а основная привлекательность перед Groovy в том, что ES можно активно использовать за пределами JVM: браузерный javascript, adobe flex/air, .net - one language to rule them all)
ну.. груви в серсии 1.6 от java, по сути, не отличается - можно переименовать .java в .groovy и с минимальными изменениями(чуть другой синтаксис для для итераций), а java'у скриптовым языком всё же сложно назвать. Т.е. один из важнейших плюсов - что это слегка раширенный синтаксис java и переучиться можно за пару недель.
ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
> ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
отсносительно groovy и python/ruby, конечно.
вот здесь можно посмотреть (но за точность тестов я не ручаюсь, конечно). Если абстрактно - JavaScript уступает и Ruby, и Python'у, т.к. разрабатывался изначально для "небольших целей".
Бред какой-то. Mozilla Rhino, о которой мы говорим, компилирует JS в байткод.
По поводу перформанса - достаточно для использования на серверах Google. Когда сделают 4 версию с опциональной статической типизацией будет куда более привлекательнее Ruby&Python на JVM.
По поводу перформанса - достаточно для использования на серверах Google. Когда сделают 4 версию с опциональной статической типизацией будет куда более привлекательнее Ruby&Python на JVM.
пардон, забыл ссылку на тест: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=jsc&lang2=python
> Когда сделают 4 версию с
а про ES4 (JS2) никто и не говорит =) вполне может быть, что не только "куда более", а "очень куда более"
> Когда сделают 4 версию с
а про ES4 (JS2) никто и не говорит =) вполне может быть, что не только "куда более", а "очень куда более"
да что ж такое-то? =) опять не ту ссылку дал. Вот: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=python (здсь сравнение JS (реализация SpiderMonkey, не Rhino) и Python; там и с Руби можно сравнить):
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=python
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=javascript&lang2=python
АВТОР!!!!!!! Все же про правописание забывать не будет хотя бы в статьях, а? А то "лямбда функций", "дискуссии в списку рассылки" режет глаз.
Строго говоря, использование множества восклицательных знаков подряд тоже не блеск правописания.
Притчу про соломинку и бревно в зрительных органах все помнят, не так ли?
Притчу про соломинку и бревно в зрительных органах все помнят, не так ли?
Я ни столько не оспариваю факта, что много восклицательных знаков это не очень правильно. Впрочем, как и слово, полностью написанное в верхнем регистре. Но это просто желание привлеч внимание автора. "Серый" метод, но действенный. А желание привлеч внимание возникло в того, что чуть выше в коментах на это обращали внимание, но прошло как глас вопиющего.
Притчу безусловно знаю. Как и сетевой этикет в плане очепяток. Однако это совершенно не повод с такому проявлению "грязнописанию". Ошибки и очепятки в коментах еще понятны, но в статье/новости... это, на мое мнение, недопустимо и напрягает. Я же не говорю о каких то стилевый претензиях, я указываю на ошибки которые элементарно отлавливаются Word-ом или FireFox (версия 3 с проверкой орфографии) еще на стадии написания поста.
Или хочеться видеть главную страницу хабра пестрящую "харошими навастями их мира ХХХ" и "карпарация ХХХ випустила праграмму YYY" ? Мне нет.
Притчу безусловно знаю. Как и сетевой этикет в плане очепяток. Однако это совершенно не повод с такому проявлению "грязнописанию". Ошибки и очепятки в коментах еще понятны, но в статье/новости... это, на мое мнение, недопустимо и напрягает. Я же не говорю о каких то стилевый претензиях, я указываю на ошибки которые элементарно отлавливаются Word-ом или FireFox (версия 3 с проверкой орфографии) еще на стадии написания поста.
Или хочеться видеть главную страницу хабра пестрящую "харошими навастями их мира ХХХ" и "карпарация ХХХ випустила праграмму YYY" ? Мне нет.
«Multiple exclamation marks are a sure sign of a diseased mind.» — Terry Pratchett.
простите у вас тут дискуссия длинная.. затяжная. я даже прочел. у меня даже вопросы появились, но я решил их не задавать. Возможно немного эгоистично, но выскажу просто мнение свое:
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лямбда вычисления и замыкание