Comments 159
хабракат нужен.
+1
интересненько...
только вот не ясненько где на практике такое можно применять ? в каких случаях ?
только вот не ясненько где на практике такое можно применять ? в каких случаях ?
0
Судя по примерам непонятно как это можно использовать(возмоэно не удачные примеры)
Зачем лямбда фукцию оборачивать в обычныю в стандартном ее понимаии? Для чего это сделано не понятно.
Я например не вижу смысла в использовании данных конструкций в таком виде в каком они представлены в примере.
Зачем лямбда фукцию оборачивать в обычныю в стандартном ее понимаии? Для чего это сделано не понятно.
Я например не вижу смысла в использовании данных конструкций в таком виде в каком они представлены в примере.
0
так вот и я не вижу - зачем такие извращения создавать если это можно сделать обычными функциями...
наверное это просто неудачный пример. Подождем 5.3 или позже погуглим примеры от разработчиков и вменяемые комментарии на этот счет
Если это лучший пример из того что найду, то я не понимаю зачем такое создали в пхп 5.3 ? чтобы еще больше усложнять свой код ?
наверное это просто неудачный пример. Подождем 5.3 или позже погуглим примеры от разработчиков и вменяемые комментарии на этот счет
Если это лучший пример из того что найду, то я не понимаю зачем такое создали в пхп 5.3 ? чтобы еще больше усложнять свой код ?
+2
UFO just landed and posted this here
class A {
var func=array();
public function _construct() {
$this->func['del']=function() {/*Some actions*/}
}
}
class A
{
public function del(...){....}
}
зачем изобретать велосипед ?:)
class A extends b,c {} - такое невозможно, а вещь довольно полезная. Но используя эту фичу, такое можно сделать реальностью.
хранить указатели на родителя и потом руками перенаправлять запросы к методам родителя ?
это изврат - хотя по сути по другому никак
лучше бы создатели пхп сделали таки множественное наследование
0
UFO just landed and posted this here
Чтобы динамически изменять методы класса уже давно в PHP есть удобный механизм __call. И не нужно извращаться с массивами. И клиент класса не знает о деталях реализации (в отличие от случая с массивами)
+1
а как понимать если он вам не понадобиться ?? зачем вы его вообще в проект класса заложили тогда если он вам не понадобится ? :) мне кажется это был просто плохой пример динамически создаваемых методов.
лично по моему убеждению все методы должны быть четко определены. и не должны создаваться,удаляться в процесс работы скрипта.
лично по моему убеждению все методы должны быть четко определены. и не должны создаваться,удаляться в процесс работы скрипта.
0
Большинство современных языков (Java, C#) отказались от множественного наследования (оно сильно усложняет логику программы и добавляет много неоднозначностей).
+2
Наверное, стоит добавить: от множественного наследования интерфейса и реализации одновременно. А вот по отдельности - другое дело. Множественное наследование реализации в виде mixins (как в ruby при импортировании модуля в класс) это очень неплохая штука, позволяет избежать дублирования кода в сложных ситуациях.
0
Иногда очень удобно передавать функцию как параметр.
Это Вам позволит, например, создать массив функций, динамически добавлять и удалять их из массива, вызывать в зависимости от ситуации: $funcArray[i]($data)
Итп... в общем можно будет провести аналогию с JavaScript'ом.
Это Вам позволит, например, создать массив функций, динамически добавлять и удалять их из массива, вызывать в зависимости от ситуации: $funcArray[i]($data)
Итп... в общем можно будет провести аналогию с JavaScript'ом.
0
а можно пример когда удобнее передавать функцию как параметр ?
очень хотелось бы в идеале иметь два примера.
1. когда функция как параметр
2. тоже самое только параметры не функция
был бы очень благодарен
очень хотелось бы в идеале иметь два примера.
1. когда функция как параметр
2. тоже самое только параметры не функция
был бы очень благодарен
0
например, правило сравнения при сортировки элемнтов массива
+2
preg_replace_callback ;)
Без callback'а вообще невозможно будет что-то сотворить...
Без callback'а вообще невозможно будет что-то сотворить...
0
Лично я использовал это для валидации форм. Есть универсальный класс валидации, который вызывает функцию, которую ему передают. А передать я ему могу функцию для проверки числа, даты и тп.
Вообще ситуации разные бывают. Например Вы хотите вызвать функцию, чтобы в результате выполнения возникло событие:
GetSomeData($someConnectionInfo, OnDataGot);
Вообще ситуаций много разных, щас туго соображаю, в голову не лезут. Но если Вы писали на яваскрипте, Вы поймёте.
Вообще ситуации разные бывают. Например Вы хотите вызвать функцию, чтобы в результате выполнения возникло событие:
GetSomeData($someConnectionInfo, OnDataGot);
Вообще ситуаций много разных, щас туго соображаю, в голову не лезут. Но если Вы писали на яваскрипте, Вы поймёте.
0
Мне кажется этого вполне хватает.
function hello($s) { echo 'Hello '.$s.'!'; }
$f='hello';
$f('world');
function hello($s) { echo 'Hello '.$s.'!'; }
$f='hello';
$f('world');
0
Functional-style(array_map, array_filter, etc) операции над массивами станут значительно удобнее использовать. В нынешней форме они феерически уродливы. Передавать название функции вместо объекта или хотя бы ссылки - кошмар.
Хотя, все это все равно выглядит костылями.
Хотя, все это все равно выглядит костылями.
+1
А чем create_function не устраивает? Я использую ее в подобных функциях. Правда код в строке писать не удобно. Но если код не большой, то это лучше чем заводить новую функцию
0
Ну вообще говоря, create_function это ужасный хак. Она создаёт функцию со случайным именем в глобальной области видимости, что не есть хорошо. К тому же, эта функция не может замыкаться на контекст (как в предлагаемом патче), в результате дополнительные параметры в неё очень проблематично передать, только как глобальные данные. Насчёт нежелания заводить новую функцию - так и не надо. Просто в примерах этого нет, но функцию можно будет написать прямо вместо параметра (так же как при create_function).
+1
как-то не очень красиво оно выглядит :( в том же python и ruby оно логичнее получается.
0
Погуглил, нашел прикол:
"Можно ли будет, познав лямда-функции C++ считать себя папой функциональщины? Что б не было как с сиплюсплюсным ООП который, к примеру, смоллтолкисты вообще таковым не считают. Вопрос чисто религиозный :)"
"Можно ли будет, познав лямда-функции C++ считать себя папой функциональщины? Что б не было как с сиплюсплюсным ООП который, к примеру, смоллтолкисты вообще таковым не считают. Вопрос чисто религиозный :)"
-1
Тем не менЕе.
0
Э-э-э-э, что-то я не понял это предложение:
"В ходе дискуссии в списку рассылки, было принято решение , что без поддержки замыканий, нет необходимости в добавить их в PHP"
Это переводчик так намудрил?
"В ходе дискуссии в списку рассылки, было принято решение , что без поддержки замыканий, нет необходимости в добавить их в PHP"
Это переводчик так намудрил?
0
В php только раз желание появлялось воспользоваться лямбда. Они там такие убогие.
А вот в ECMAScript использую постоянно, очень удобно!
А вот в ECMAScript использую постоянно, очень удобно!
+2
http://wiki.php.net/rfc/closures
вот тут расписано куда более понятно как и зачем будут лямбда функции и замыкания работать в пхп
вот тут расписано куда более понятно как и зачем будут лямбда функции и замыкания работать в пхп
0
UFO just landed and posted this here
Не поделитесь, зачем вам множественное наследование в PHP?
+1
UFO just landed and posted this here
Каша какая-то.
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
Если классу А и классу Б нужен доступ к закрытым методам класса C, то их нужно делать наследниками С, а не наоборот.
Если классу С требуется доступ к закрытым методам А и Б, то у вас, скорее всего, что-то не так с архитектурой.
Второй пример. Вы уж определитесь, что наследуется, закрытые методы или права ACL. Если методы - см. пункт 1, если права - то реализовывать их через отдельные классы глупо.
0
UFO just landed and posted this here
Да - таки "зло".
При использовании множественного наследования возникает целая куча спорных ситуаций. Таких например как "какой метод одного из родителей использовать, если в обоих родительских классах есть методы с одинаковыми названиями?"
далее. если Вам необходим доступ к методам двух "родителей", то возможно Вам нужно делегирование объектов, а не множественное наследование?
Желание работать с множественным наследованием возникает из-за непонимания сути ООП, из-за мыслей что "это круто!!!" и из-за недостаточного опыта разработки...
Поверьте - многие из тех, кто ощутил прелесть множественного наследования, сожалеют что оно есть. Сам же я на практике множественное наследование не возжелал ни разу, а проекты, поверьте, выходят далеко за грани форумов и гостевых книг ;) :)
При использовании множественного наследования возникает целая куча спорных ситуаций. Таких например как "какой метод одного из родителей использовать, если в обоих родительских классах есть методы с одинаковыми названиями?"
далее. если Вам необходим доступ к методам двух "родителей", то возможно Вам нужно делегирование объектов, а не множественное наследование?
Желание работать с множественным наследованием возникает из-за непонимания сути ООП, из-за мыслей что "это круто!!!" и из-за недостаточного опыта разработки...
Поверьте - многие из тех, кто ощутил прелесть множественного наследования, сожалеют что оно есть. Сам же я на практике множественное наследование не возжелал ни разу, а проекты, поверьте, выходят далеко за грани форумов и гостевых книг ;) :)
0
UFO just landed and posted this here
нет - ACL не зло. Но реализовывать его множественным наследованием.. гы. по меньшей мере странно.
Вы впадаете в крайности. Умение управлять сложностью не менее важно чем уметь программить в принципе. Код должен быть изначально понятен человеку, а уже потом машине.
Суть ООП в том, что бы представлять структуры в более логическом и взаимосвязанном виде (не путать со связностью).
Верю. Вы программите долго. Вы даже старше меня. Но даже если это и так - это не означает что опыта у Вас больше. Да - таков парадокс...
Да что Вы к этим минусам? ))) Меня так же загнали - я ж не плачу...
Вы впадаете в крайности. Умение управлять сложностью не менее важно чем уметь программить в принципе. Код должен быть изначально понятен человеку, а уже потом машине.
Суть ООП в том, что бы представлять структуры в более логическом и взаимосвязанном виде (не путать со связностью).
Верю. Вы программите долго. Вы даже старше меня. Но даже если это и так - это не означает что опыта у Вас больше. Да - таков парадокс...
Да что Вы к этим минусам? ))) Меня так же загнали - я ж не плачу...
0
> Вы даже старше меня.
Улыбнуло))
ЗЫ. Для ленивых: creOtiv и AlexeyTokar - одногодки ;-)
Улыбнуло))
ЗЫ. Для ленивых: creOtiv и AlexeyTokar - одногодки ;-)
0
UFO just landed and posted this here
А, простите, в каком банке Вы работаете? Или для какого банка пишете?
0
> И с какой это башеи зеленой вы взяли что вы програмите лучше меня? Вы видели как я пишу?
Я думаю, достаточно полистать ваш ЖЖ, чтобы определить уровень вашей подкованности. А банк... банку только минус за экономию денег на ИТ-отделе.
Я думаю, достаточно полистать ваш ЖЖ, чтобы определить уровень вашей подкованности. А банк... банку только минус за экономию денег на ИТ-отделе.
0
UFO just landed and posted this here
Фи как некрасиво) смарти зло))
0
UFO just landed and posted this here
Не всегда шаблоны будете сами писать. Бывает, что этим занимаются сторонние люди, которым легче выучить синтаксис smarty, который в свою очередь похож на кучу других шаблонизаторов, так что схавается легче. Плюс смарти расширяем...
0
UFO just landed and posted this here
не вижу извращения. смарти код гораздо чище => понятнее для понимания.
А зачем ему учить пхп? Разница, скажем так, в объёме материала для изучения. Мануал смарти маленький и понятный.
А зачем ему учить пхп? Разница, скажем так, в объёме материала для изучения. Мануал смарти маленький и понятный.
0
Видимо имеется ввиду тот момент, что:
1. ПХП изначально предназначался в качестве "клея" между данными и представлением.
1. смарти использует свой язык, так сказать получилось "еще одно ПХП, написанное на ПХП".
1. ПХП изначально предназначался в качестве "клея" между данными и представлением.
1. смарти использует свой язык, так сказать получилось "еще одно ПХП, написанное на ПХП".
0
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}
0
UFO just landed and posted this here
Функционал смарти меньше? Чем это он меньше? Примеры в студию (на пастбин). Смарти чище. Спросите свою подругу, что ей приятнее для глаза.
>Вот как вы например на смарти реализуете >рекурсию?
Давайте конкретную задачу. Если вы про создание и вызов функции, которая, в свою очередь, будет запускать себя же, то я просто напишу плагин для смарти.
>Я на смарти писал под 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.
0
UFO just landed and posted this here
ладно. показываю для особо крутых программистов как выглядит вывод дерева, который хранится как список смежностей (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. по поводу тормознутости - система кэширования и компилируемые шаблоны спасают, но то, что это дополнительная нагрузка - с этим согласен.
+1
ну а я по-вашему молодым специалистом небыл? :)
почему бы не смотреть на pctools.com или magentocommerce.com, м?
почему бы не смотреть на pctools.com или magentocommerce.com, м?
0
UFO just landed and posted this here
Я согласен с Алексеем, надо грамотно и без фанатизма пользоваться.
И не кричать фреймворки - круто, множественная наследственность тоже круто...
Нужно спокойно и размеренно, анализируя архитектуру, применять нужное решение.
Как пользоваться инструментарием - дело самого разработчика. Чем больше вы усложняете "систему" - тем больше вероятность встречи глюка, бага. Я считаю наоборот - надо "систему(разработку)" как можно более упрощать, унифицировать и т.п.
И не кричать фреймворки - круто, множественная наследственность тоже круто...
Нужно спокойно и размеренно, анализируя архитектуру, применять нужное решение.
Как пользоваться инструментарием - дело самого разработчика. Чем больше вы усложняете "систему" - тем больше вероятность встречи глюка, бага. Я считаю наоборот - надо "систему(разработку)" как можно более упрощать, унифицировать и т.п.
0
какой-то хреновый у вас acl. каждая группа пользователя это отдельный класс? про сущности вообще что-нибудь слышали?
Вы приведите нормальный пример, когда использование множественного наследования действительно необходимо? Хотя лично я считаю, что это дело вкуса, но ведь не зря же во многих языках убрали множественное наследование?
Вы приведите нормальный пример, когда использование множественного наследования действительно необходимо? Хотя лично я считаю, что это дело вкуса, но ведь не зря же во многих языках убрали множественное наследование?
0
я могу поделиться примером из жизни (если можно реализовать более красиво, то буду признателен):
есть класс UserSession (класс работы с сессиями, авторизацией и т.п.), есть класс UserSettings (личные настройки пользователя на сайте), и такие классы с отдельной логикой могут появляться в дальнейшем.
Поэтому мне кажется удобным в этом случае использовать множественное наследование, когда я могу получить доступ к любой функции перечисленных выше классов через класс User (как точка доступа ко всем классам, касающимся пользователя).
Разве это не удобно?
есть класс UserSession (класс работы с сессиями, авторизацией и т.п.), есть класс UserSettings (личные настройки пользователя на сайте), и такие классы с отдельной логикой могут появляться в дальнейшем.
Поэтому мне кажется удобным в этом случае использовать множественное наследование, когда я могу получить доступ к любой функции перечисленных выше классов через класс User (как точка доступа ко всем классам, касающимся пользователя).
Разве это не удобно?
0
О том, почему такого нельзя делать, исписано множество книг по ООП. Наследование (открытое) должно обозначать связь типа "является". Т.е. в вашем случае "User является (подвидом) UserSettings), что неверно. Причин, по которым нельзя в этом случае использовать наследование много. Самая простая - увеличивается связность классов между собой. Впоследствии не получится изменить способ работы с настройками пользователя - он будет жёстко привязан к интерфейсу вашего класса UserSettings, а сессии - к классу UserSession. В этом нет ничего плохого на этапе первоначальной разработки, но если потом пытаться улучшать или модифицировать этот код - проще будет написать новый :)
0
спасибо за ответ, но я не понял :)
Мне кажется, что множественное наследование не поддерживается php, java, C# не по причинам того, что его плохо применяют, и от этого ухудшается отслеживание кода. Т.е. если классы от которых происходит множественное наследование могут иметь общего родителя (где-то далеко) или т.п. - могут возникнуть разные косяки... Но если классы находятся в перпендикулярных плоскостях, то я не вижу чем плохо множественное наследование. Я в своем примере использую совершенно несвязанные по логике классы (настройки, сессии и т.п.). А класс User является просто точкой "входа". Т.е. класс User не имеет собственных методов и классов. И для того, чтобы мне что-то поменять, мне нужно всего лишь поменять один из классов родителей.
Мне кажется тут уместно использование множественного наследования, разве нет?
Мне кажется, что множественное наследование не поддерживается php, java, C# не по причинам того, что его плохо применяют, и от этого ухудшается отслеживание кода. Т.е. если классы от которых происходит множественное наследование могут иметь общего родителя (где-то далеко) или т.п. - могут возникнуть разные косяки... Но если классы находятся в перпендикулярных плоскостях, то я не вижу чем плохо множественное наследование. Я в своем примере использую совершенно несвязанные по логике классы (настройки, сессии и т.п.). А класс User является просто точкой "входа". Т.е. класс User не имеет собственных методов и классов. И для того, чтобы мне что-то поменять, мне нужно всего лишь поменять один из классов родителей.
Мне кажется тут уместно использование множественного наследования, разве нет?
0
Наследование "ромбом" в основном имеет проблемы в компилируемых языках, потому что приходится вводить для него много частных случаев общих в остальном принципов.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
Возможно, я непонятно объяснил потому что у меня использование делегирования в указанных вами случаях уже на уровне чувств. Проблемы в случае наследования User от UserSession и UserSettings будут тогда, например, когда вам нужно будет немного изменить логику Userа по работе с настройками, а изменить UserSettings вы не сможете потому что он используется где-то в другом месте. Или наоборот - нужно будет немного изменить UserSettings, а вы не сможете, потому что User слишком много знает о его внутреннем устройстве. Это не проблемы уровня первоначальной реализации - там можно делать практически как угодно. Это проблемы последующей поддержки кода. А, как известно, в нормальных проектах на поддержку тратится куда больше времени и сил чем на первоначальную разработку.
0
Вообще-то в Вашем случае, по-хорошему, стоит делегировать два объекта (от USettings и USession) в класс User (сделать свойствами, к примеру), но никак не наследовать от этих классов
+1
ну в сущности я и сделал делегирование. класс User имеет свойства, в которых экземпляры классов USettings и USession, но ведь глобально это просто способ реализовать множественное наследование (из-за того, что его нет).
0
Глобально, вам выше пытались сказать, что это разные вещи :)
Возможно пример с пользователем не так нагляден, попробую привести другой. Если есть класс ноги и руки, то класс человека не является производным от них.
Возможно пример с пользователем не так нагляден, попробую привести другой. Если есть класс ноги и руки, то класс человека не является производным от них.
0
да, хороший пример!!! Спасибо. Вот теперь я понял почему отказались от множественного наследования - было бы оно - я бы не сильно переживая замутил его, а так пришлось делать правильно:)
0
Было бы крайне забавно узнать, как относятся ламбды и замыкания к реализации множественного наследования.
0
UFO just landed and posted this here
ага:) уже столько комментов упоминает это, а так и не пойму реализацию.
Я для реализации множественного наследования в пхп использую рефлексию...
Я для реализации множественного наследования в пхп использую рефлексию...
0
всё это конечно прекрасно, но замыкания позволяют писать адски трудные для понимания костыли :)
Так мы придем к perl в котором один "профессионал" может написать код который не поймет ни один другой "профессионал" :)
Так мы придем к perl в котором один "профессионал" может написать код который не поймет ни один другой "профессионал" :)
0
ещё один метод суицида для гавнокодеров. я уже в ужасе от перспективы править подобный код. а сам в ближайшее время буду использовать сиё только в спорах о крутости языка.
-1
множественное наследование - ЗЛО
анонимные функции - ЗЛО
по-моему самое полезное из того, что стоит ждать в 5.3 - LSB
анонимные функции - ЗЛО
по-моему самое полезное из того, что стоит ждать в 5.3 - LSB
-2
кстати...
замыкание - ЗЛО :)
без него можно вполне обойтись, используя грамотную архитектуру классов
замыкание - ЗЛО :)
без него можно вполне обойтись, используя грамотную архитектуру классов
-1
на actionscript благодаря анонимным функциям и замыканиям количество методов в классе уменьшается ровно вдвое, не говоря уже про читабельность
в яве вовсю используются объектные аналоги анонимных функций - анонимные классы
в яве вовсю используются объектные аналоги анонимных функций - анонимные классы
0
Мой вам совет: не высказывайте подобных мыслей в присутствии Ruby-стов. Засмеют :)
Да и вообще можно обойтись не только без замыканий но и без ООП, без языков высокого уровня и даже без компьютера! :) Зачем это все? И вообще, считать надо в уме. На свежем воздухе :)
Да и вообще можно обойтись не только без замыканий но и без ООП, без языков высокого уровня и даже без компьютера! :) Зачем это все? И вообще, считать надо в уме. На свежем воздухе :)
-2
scala и Erlang просто пронизаные анонимными функциями, и злом их подавно никто не считает
зы Скала может стать преемником явы
ззы про эрланг итак все знают
зы Скала может стать преемником явы
ззы про эрланг итак все знают
0
использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение.
0
гениально !
так и запишу
мартину одерски, гостлингу и другим уже сел писать письмо - дескать, мужики то и не знали
так и запишу
мартину одерски, гостлингу и другим уже сел писать письмо - дескать, мужики то и не знали
0
вы это скажите в rsdn.declarative
0
Да не трогайте вы его) Человек всю жизнь на PHP пишет, а вы ему скалкой и эрлангом тыкаете. Кложеры будут до PHP доходить как и ООП - пару лет минимум.
+1
Прежде чем делать какие-либо заявления, нужно быть в них уверенным.
А Вы попросту пытаетесь умничать
А Вы попросту пытаетесь умничать
-1
а что тут доказывать ? что кетчуп не зеленый ? элементы функционального программирования есть/вводятся во все более-менее основные языки программирования, фп имеет под собой мощную математическую базу, На декларативных языках очень многое пишется быстрее и короче; во многих случаях реализуется такое, что империативным путем не реализуется впринципе
И тут некто заявляет(без каких-либо аргументов, что самое важное), что это фп - зло. Это просто несерьезно
И тут некто заявляет(без каких-либо аргументов, что самое важное), что это фп - зло. Это просто несерьезно
0
я так понимаю, это и есть вся аргументация ?
+1
это к тому, что Вы даже не удосужились проверить метафору, которую употребляете. А значит так у Вас везде...
0
Нужно быть не уверенным в заявлениях, а как минимум разбираться в вопросе. Или хотя бы прислушиваться к тому, что люди говорят. А уверенность без понимания сути это, уж простите, ламерством называлось всегда.
0
Нужно не прислушиваться к тому, что говорят люди, а САМОМУ проверять и делать выводы.
В противном случае мы превратимся в стадо овец, которых ведет один пастух
В противном случае мы превратимся в стадо овец, которых ведет один пастух
0
Вот и прислушайтесь. Вам уже несколько человек намекнули, что ваша позиция, мягко говоря, несостоятельная. На что им щедро «te;кто-то» наставил минусов, да и карму уменьшил. Хотя беседа вполне мирная. Вы еще не привели ни одного веского аргумента против замыканий. У меня складывается впечатление, что говорите вы это либо просто по наслышке, либо пытались применить инструмент не по назначению. Непременно, микроскопом забивать гвозди менее удобно, нежели молотком. А вот как объяснить человеку, пробовавшему микроскоп в этом качестве и уверенному, что «микроскоп это полная чушь»... как ему объяснить, что микроскоп создавался несколько для других целей?
Замыкания и лямбда функции это замечательный инструмент, который в умелых руках, позволяет добиваться потрясающей эффективности, лаконичности и понятности кода. Притом что количество ошибок снижается на порядок.
Эта идея является центральной в таких языках как Lisp, Erlang. В Ruby замыкания применяются практически везде. Благодаря этому, можно написать одну строку, которая была бы эквивалентна десятку строк на императивном языке, тем не менее, оставаясь абсолютно прозрачной и читаемой.
Я почти уверен в том, что ни одного из вышеперечисленных языков вы не знаете. Особенно это касается Ruby. Если бы вы поняли этот язык, то фразы типа «использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение», вы воспринимали бы не иначе как бред. Я мог бы привести соответствующие куски кода, вот только боюсь что вас они не впечатлят (как впрочем и все остальное по этой теме).
Простите, но на «пастуха» вы никак не тянете.
Замыкания и лямбда функции это замечательный инструмент, который в умелых руках, позволяет добиваться потрясающей эффективности, лаконичности и понятности кода. Притом что количество ошибок снижается на порядок.
Эта идея является центральной в таких языках как Lisp, Erlang. В Ruby замыкания применяются практически везде. Благодаря этому, можно написать одну строку, которая была бы эквивалентна десятку строк на императивном языке, тем не менее, оставаясь абсолютно прозрачной и читаемой.
Я почти уверен в том, что ни одного из вышеперечисленных языков вы не знаете. Особенно это касается Ruby. Если бы вы поняли этот язык, то фразы типа «использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение», вы воспринимали бы не иначе как бред. Я мог бы привести соответствующие куски кода, вот только боюсь что вас они не впечатлят (как впрочем и все остальное по этой теме).
Простите, но на «пастуха» вы никак не тянете.
+1
=)) Поподробней с этого места, если можно. Вы, вообще, знакомы с функциональным программированием?
0
естественно. и именно из-за знакомство с ним, предпочитаю императивное и объектно-ориентированное программирование ;)
0
Я тоже знаком и с императивным стилем (и с функциональным; я, вообще, больше JavaScript-программист, хоть и занимаюсь PHP на серверной стороне), и с ООП-парадигмой =) Мне просто интересно, - конкретная аргументация есть вот на это:
> использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение
и на это:
> замыкание - ЗЛО :)
Может пример приведете?
Я могу конкретный пример привести, когда анонимная функция - это "зло", но это "зло" занимает лишь 5% от мощи замыканий и анонимных функций.
> использование анонимных функций - первый признак того, что вы не понимаете что должно делать приложение
и на это:
> замыкание - ЗЛО :)
Может пример приведете?
Я могу конкретный пример привести, когда анонимная функция - это "зло", но это "зло" занимает лишь 5% от мощи замыканий и анонимных функций.
0
конкретная аргументация.
В мире, в котором живу я (не будем говорить что Вы сейчас в топике о РНР - это не к месту), базовая логическая структура разработки - функция. Именно на функциях основывается логический смысл программы. Именно функция имеет вполне конкретную, достаточную и четкую логику и границу. Именно функции представляет из себя кирпичики из которых в последствии (при взаимодействии через операторы) должно получиться то, что Вы возможно называете ПО, которое имеет вполне конкретную бизнес-логику.
насчет "замыкание - ЗЛО":
порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
Если в Ваших проектах есть те, что покрывают более нескольких десятков тысяч строк - Вы возможно меня поймете.
Вообще против ФП как парадигдмы я ничего не имею, но из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций, а так же повсеместные рекурсии, для себя я его не рассматриваю как "идею будущего".
В мире, в котором живу я (не будем говорить что Вы сейчас в топике о РНР - это не к месту), базовая логическая структура разработки - функция. Именно на функциях основывается логический смысл программы. Именно функция имеет вполне конкретную, достаточную и четкую логику и границу. Именно функции представляет из себя кирпичики из которых в последствии (при взаимодействии через операторы) должно получиться то, что Вы возможно называете ПО, которое имеет вполне конкретную бизнес-логику.
насчет "замыкание - ЗЛО":
порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
Если в Ваших проектах есть те, что покрывают более нескольких десятков тысяч строк - Вы возможно меня поймете.
Вообще против ФП как парадигдмы я ничего не имею, но из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций, а так же повсеместные рекурсии, для себя я его не рассматриваю как "идею будущего".
0
«из-за того, что оно вынуждает использовать кругом копии элементов вместо присвоений и повторных операций»
Опять же, обратитесь к Ruby.
Опять же, обратитесь к Ruby.
0
Ну, первый абзац, простите, ни о чем (простая демагогия, придание воды).
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)
> вместо присвоений
Принимается. Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
Однако, "захват нужного контекста" (а в этом патче и вообще, как я вижу, можно только определенный набор передавать в замыкание из родительского скопа; в JS - весь скоп родительский попадает), "незасорение глобального скопа", и т.д. в этих случае - вещь очень удобная.
> Вообще против ФП как парадигдмы я ничего не имею
Да я, вообще-то, тоже - ни против ФП, ни ИП. Я вправе использовать оба стиля. Меня просто всегда "умиляют" подобные ярые выкрики, основанные часто лишь на личных привычках и не более (надеюсь, что у вас не так =)
0
> Если описать функцию в уже выделенном под нужды скопе (только не глобальном, т.к. это, как раз-таки, аргумент в пользу анонимных функций при передаче в качестве параметров) - сослаться на нее будет по ресурсам менее затратно, чем плодить каждый раз новую функцию.
То есть, вы говорите, что тот же clisp для двух (fn (a b) (+ a b)) в разных участках кода сгенерит ДВА РАЗНЫХ куска кода? ;-)
То есть, вы говорите, что тот же clisp для двух (fn (a b) (+ a b)) в разных участках кода сгенерит ДВА РАЗНЫХ куска кода? ;-)
0
неа, я с 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% "зла" анонимных функций, о которых я отмечал человеку, ставящему всем минусы, заканчиваются.
0
В таком случае ООП - не меньшее зло чем анонимные функции ;-)
0
> В таком случае
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
Не "в таком случае", а "относительно" =) Любая высокая абстракция всегда несет за собой потери в ресурсах (ООП сюда тоже входит), но вряд ли это стоит приводить примером. В моем примере выше - всего лишь оптимизация в случае, если функция семантически одинакова для всех (ведь на лицо же - 100 функций сидящий в памяти будут жрать в 100 раз больше ресурсов, чем одна).
Касательно ООП - динамическая модель, где есть только объекты и сообщения (первоначальная концепция Алана Кея (ООП из Smalltalk'a); "истинное ООП") - также, естественно, по ресурсам более затратно, чем ООП, основанное на классах, где нет возможности расширять динамически классы/объекты и инстансы классов/объектов. Но вместе с тем, оно более гибко, т.е., опять же, за более высокую абстракцию - платятся бОльшие ресурсы.
+1
Замените
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 раз больше ресурсов
А вот тут вы заблуждаетесь ;-)
+1
> и скажите, что с точки зрения ресурсоемкости (точнее, ресурсопрожорливости) поменялось.
=) ничего не поменялось, посмотрите разделы "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
> А вот тут вы заблуждаетесь ;-)
неа =) но все же спрошу - а где? =)
+1
> ничего не поменялось
что и требовалось доказать для фразы "ООП - зло"))
Касательно анонимных функций и случая со 100 копиями функции.
Если рассуждать логически, компилятор, вместо генерации 100 копий анонимной функции можно использовать ссылку на одну и ту же функцию, до тех пор, пока это возможно (т.е. пока вы не решите, эм.. модифицировать тело функции ;-). В этом, разумеется, _частном случае_ затраты на оставшиеся 99 функций будут близки к нулю. Исключение из этого - необходимость хранение контекста функции, но это несколько иной случай ;-)
что и требовалось доказать для фразы "ООП - зло"))
Касательно анонимных функций и случая со 100 копиями функции.
Если рассуждать логически, компилятор, вместо генерации 100 копий анонимной функции можно использовать ссылку на одну и ту же функцию, до тех пор, пока это возможно (т.е. пока вы не решите, эм.. модифицировать тело функции ;-). В этом, разумеется, _частном случае_ затраты на оставшиеся 99 функций будут близки к нулю. Исключение из этого - необходимость хранение контекста функции, но это несколько иной случай ;-)
0
>> ничего не поменялось
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
я, надеюсь, понятно, что мы утрировали и "не поменялось" касалось лишь количества - и там, и там - 100 объектов будет создано (в реале же разница - в первом случае 100 функций, во втором - 100 объектов, созданных на основе функции-конструктора Foo)
> что и требовалось доказать для фразы "ООП - зло"))
не понял, что вы имеете в виду (да и - касательно "ООП - зло" - я этого не говорил)
> Касательно анонимных функций и случая со 100 копиями функции.
> Если рассуждать логически
если логически - то все хорошо, но если заглянуть в спецификацию ECMAScript - то 100 функций.
0
ай-яй-яй.. Прошу меня извинить, я привел самый неудачный пример из всех, из которых можно было бы привести (с циклами; но это касается только 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);
0
UFO just landed and posted this here
> порождать бессмысленные структуры языка программирования (местами с полным копированием) есть не что иное, как диверсия против разработчиков, сопровождающих проект.
В таком случае, ООП не меньшее зло - ибо разницы между штампованием объектов и штампованием анонимных функций нет.
В таком случае, ООП не меньшее зло - ибо разницы между штампованием объектов и штампованием анонимных функций нет.
+1
Ну как же?
Объект инкапсулирует поведение внутри себя (точнее этим класс занимается), а анонимная функция, одинаковой логики в двух местах полностью повторяет свой код, что непременно ведет к усложнению.
Это конечно если анонимные функции использовать по назначению, а не просто присваивать их переменной как показано выше, что совершенно противоречит ФП, о котором автор ведет речь, и в котором состояние системы в момент времени отсутствует по определению
Объект инкапсулирует поведение внутри себя (точнее этим класс занимается), а анонимная функция, одинаковой логики в двух местах полностью повторяет свой код, что непременно ведет к усложнению.
Это конечно если анонимные функции использовать по назначению, а не просто присваивать их переменной как показано выше, что совершенно противоречит ФП, о котором автор ведет речь, и в котором состояние системы в момент времени отсутствует по определению
-2
> что совершенно противоречит ФП, о котором автор ведет речь
Демагогия и глупая подмена понятий, не более. Речь в примере не о ФП, а лишь об анонимной функции.
Еще раз, человек, если вы не понимаете что-то, то это не значит, что это плохо.
P.S.: небось руки уже снова чешутся кнопочку "минус" всем нажать? =))
Демагогия и глупая подмена понятий, не более. Речь в примере не о ФП, а лишь об анонимной функции.
Еще раз, человек, если вы не понимаете что-то, то это не значит, что это плохо.
P.S.: небось руки уже снова чешутся кнопочку "минус" всем нажать? =))
0
Господи, да что ж Вас так писькомерка-то волнует? :) Не растет чтоли?
Разводить спор с фанатиком далее смысла не вижу. Вы - педант
Разводить спор с фанатиком далее смысла не вижу. Вы - педант
-2
А в ассемблере вся логика строится на goto (jmp).
0
товарищу, который ставит минус - аргументируйте, не стесняйтесь
сообщество с удовольствием посмотрик, как вы перепишите без фп, скажем, амазоновские сервисы для нагруженных приложений, ну или простейший примерчик lazy evoluation сделает,,, хотя сгодится и пара-тройка миллионов потоков, запущенных на одной машине
сообщество с удовольствием посмотрик, как вы перепишите без фп, скажем, амазоновские сервисы для нагруженных приложений, ну или простейший примерчик lazy evoluation сделает,,, хотя сгодится и пара-тройка миллионов потоков, запущенных на одной машине
+1
скала слишком сложная, чтобы стать преемником, у groovy-то больше шансов.
0
ммм,,, груви тормозит вследствие динамической типизации - врядли на критическиех задачах будут его использовать, в этой области у скалы преимущество
хотя мне, и то, и другое по душе - главное, чтобы было к месту
хотя мне, и то, и другое по душе - главное, чтобы было к месту
0
да, скорость - не самое сильное место groovy, но в 1.6 они уже значительно прибавили, а если в java7 сделают invokedynamic то жить станет ещё проще :) кстати замыканию вполне могут попасть в java7.
я был бы очень рад, если б groovy стал третьим включённым в jvm языком, наряду с java и javaFX.
я был бы очень рад, если б groovy стал третьим включённым в jvm языком, наряду с java и javaFX.
0
Второй язык на данный момент лежит в javax.script - реализация JavaScript под названием Mozilla Rhino. JavaFX ещё не включён да и вообще пока что больше мертворожденного напоминает, особенно после ухода Ганса Мюллера в Адоб. Invokedynamic далеко не панацея для динамических языков. Я лично очень жду когда реализуют в Rhino четвёртую спеку ES.
0
Про рино я в курсе, но он всё-таки скриптовый язык, чистый классна нём так просто не напишешь, насколько я понимаю, в отличии от groovy.
JavaFX в update 10 должен войти. GraphicsBuilder из groovy умеет многие фичи из JavaFX.
JavaFX в update 10 должен войти. GraphicsBuilder из groovy умеет многие фичи из JavaFX.
0
Хм... А Groovy не скриптовой что-ли? Rhino используется очень активно в Google, они кстати и будут основные коммитеры 4 версии. А она по функционалу очень крутая - не уступает Ruby & Python, а самое главное там будет в отличие от них опциональное статическое типизирование. Ну а основная привлекательность перед Groovy в том, что ES можно активно использовать за пределами JVM: браузерный javascript, adobe flex/air, .net - one language to rule them all)
0
ну.. груви в серсии 1.6 от java, по сути, не отличается - можно переименовать .java в .groovy и с минимальными изменениями(чуть другой синтаксис для для итераций), а java'у скриптовым языком всё же сложно назвать. Т.е. один из важнейших плюсов - что это слегка раширенный синтаксис java и переучиться можно за пару недель.
ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
0
> ну плюсы javascript'а-то понятны, как, впрочем, и минусы. А как у него с перфомансом?
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
перфоманс относительно чего? Например, C++: JavaScript (нынешние реализации) медленней C++ в 50-200 раз (из-за интерпритируемости, динамического ООП на прототипах, тех же замыканий и анонимных функций, о которых тут идет речь).
0
отсносительно groovy и python/ruby, конечно.
0
вот здесь можно посмотреть (но за точность тестов я не ручаюсь, конечно). Если абстрактно - JavaScript уступает и Ruby, и Python'у, т.к. разрабатывался изначально для "небольших целей".
0
Бред какой-то. Mozilla Rhino, о которой мы говорим, компилирует JS в байткод.
По поводу перформанса - достаточно для использования на серверах Google. Когда сделают 4 версию с опциональной статической типизацией будет куда более привлекательнее Ruby&Python на JVM.
По поводу перформанса - достаточно для использования на серверах Google. Когда сделают 4 версию с опциональной статической типизацией будет куда более привлекательнее Ruby&Python на JVM.
0
пардон, забыл ссылку на тест: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=jsc&lang2=python
> Когда сделают 4 версию с
а про ES4 (JS2) никто и не говорит =) вполне может быть, что не только "куда более", а "очень куда более"
> Когда сделают 4 версию с
а про ES4 (JS2) никто и не говорит =) вполне может быть, что не только "куда более", а "очень куда более"
0
да что ж такое-то? =) опять не ту ссылку дал. Вот: 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
0
UFO just landed and posted this here
АВТОР!!!!!!! Все же про правописание забывать не будет хотя бы в статьях, а? А то "лямбда функций", "дискуссии в списку рассылки" режет глаз.
+2
Строго говоря, использование множества восклицательных знаков подряд тоже не блеск правописания.
Притчу про соломинку и бревно в зрительных органах все помнят, не так ли?
Притчу про соломинку и бревно в зрительных органах все помнят, не так ли?
+2
Я ни столько не оспариваю факта, что много восклицательных знаков это не очень правильно. Впрочем, как и слово, полностью написанное в верхнем регистре. Но это просто желание привлеч внимание автора. "Серый" метод, но действенный. А желание привлеч внимание возникло в того, что чуть выше в коментах на это обращали внимание, но прошло как глас вопиющего.
Притчу безусловно знаю. Как и сетевой этикет в плане очепяток. Однако это совершенно не повод с такому проявлению "грязнописанию". Ошибки и очепятки в коментах еще понятны, но в статье/новости... это, на мое мнение, недопустимо и напрягает. Я же не говорю о каких то стилевый претензиях, я указываю на ошибки которые элементарно отлавливаются Word-ом или FireFox (версия 3 с проверкой орфографии) еще на стадии написания поста.
Или хочеться видеть главную страницу хабра пестрящую "харошими навастями их мира ХХХ" и "карпарация ХХХ випустила праграмму YYY" ? Мне нет.
Притчу безусловно знаю. Как и сетевой этикет в плане очепяток. Однако это совершенно не повод с такому проявлению "грязнописанию". Ошибки и очепятки в коментах еще понятны, но в статье/новости... это, на мое мнение, недопустимо и напрягает. Я же не говорю о каких то стилевый претензиях, я указываю на ошибки которые элементарно отлавливаются Word-ом или FireFox (версия 3 с проверкой орфографии) еще на стадии написания поста.
Или хочеться видеть главную страницу хабра пестрящую "харошими навастями их мира ХХХ" и "карпарация ХХХ випустила праграмму YYY" ? Мне нет.
0
«Multiple exclamation marks are a sure sign of a diseased mind.» — Terry Pratchett.
0
простите у вас тут дискуссия длинная.. затяжная. я даже прочел. у меня даже вопросы появились, но я решил их не задавать. Возможно немного эгоистично, но выскажу просто мнение свое:
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
Замыкание - это технология и инструмент, как и ооп. Те кто могут жить на этом уровне абстракций и успешно живут, те им пользуются, кто не могут, те не пользуются. Но говорить о том что это нововведение есть фигня некорректно как минимум потому, что другие уверены что оно им нужно.
лично я пока не представляю как использовать замыкания буду, потому что до этого использовал их в событийных языках только широко (пример JavaScript).
0
Sign up to leave a comment.
Лямбда вычисления и замыкание