Ась? Нормальные дженерики сделали (ала С#) ? или делегаты ? или лямбда ф-ции ? overhead по памяти уменьшили ? код классов (не системных) классов шарится между жвм-ами? Что досих пор нет? Nah!
>Ась? Нормальные дженерики сделали (ала С#) ? или делегаты ? или лямбда ф-ции ? overhead по памяти уменьшили ? код классов (не системных) классов шарится между жвм-ами? Что досих пор нет? Nah!
Делегаты - избыточная сущность для недоучек, неспособных правильно проектировать интерфейсы.
>Делегаты - избыточная сущность для недоучек, неспособных правильно проектировать интерфейсы.
А вы как видно сударь большой ученый? Ну так просветите, как правильно спроектировать интерфейс, например, с одним методом, возвращающим void и принимающим ... ну скажем Object. Я конечно понимаю, что простым путем вы непойдете и продемонстрируете нечто ну ооооочень изящное и свежее (а не дурацкую реализацию интерфейса внутренним классом). Ну и заодно объясните, в каком это месте делегаты избыточны, ведь даже в классических Чисто-Объектных (а не ОО) языках, как Smalltalk или Effel изпользуют именно делегаты (селекторы в Smalltalk и агенты в Effel) - а уж "авторитет" этих язЫков признан самым почтенными и авторитетными "ПрафэсОрами", каким вы без сомнения (судя по стилю изложения и глубине мыслей) и являетесь.
> Ну так просветите, как правильно спроектировать интерфейс, например, с одним методом, возвращающим void и принимающим ... ну скажем Object. Я конечно понимаю, что простым путем вы непойдете и продемонстрируете нечто ну ооооочень изящное и свежее (а не дурацкую реализацию интерфейса внутренним классом).
Я бы сделал интерфейс не внутренним классом, а обычным интерфейсным классом, лежащим в пакете рядом с теми же классами, которые этот интерфейс используют. Приношу извинения, если стиль изложения ввёл Вас чем-то в заблуждение или смущение, но не нравятся мне делегаты. И анонимные классы тоже ненравятся.
>Писать быстро и качественно можно в конце концов и на ассемблере, главное иметь библиотеку грамотно спроектированных макросов :)
Нет, главное, это чтобы индусы в этой библиотеке смогли разобраться :)
>Да, господа, и когда у вас будут полноценные замыкания?
Когда без них просто невозможно станет писать ОО программы, тогда их придется ввести в язык. Пока же нуждаются в замыканиях только академики и уникум Слава Пестов.
> код классов (не системных) классов шарится между жвм-ами? Что досих пор нет?
Меня, все же, умиляют персонажи, которые в любом топике по Java начинают нести свет в массы про то, какой Java отстой и какой замечательный язык [...] (нужное вписать), ибо там реализованы все известные персонажу академические концепции. Цель-то какая преследуется, не очень понятно?
уменьшить количество дебилов в айти вообще и в человечестве в частности. что тут сложного?
чем меньше биомусора в обществе тем легче ему (обществу) живется.
это же элементарно, nest pa?
> уменьшить количество дебилов в айти вообще и в человечестве в частности. что тут сложного? чем меньше биомусора в обществе тем легче ему (обществу) живется. это же элементарно, nest pa?
Да уж не бином Ньютона. Комплекс собственной болезненной исключительности имени Луговского тут многих мучает.
> Чисто-Объектных (а не ОО) языках, как Smalltalk или Effel изпользуют именно делегаты
Так я и знал! Скоро будет заявлено что это изобретение M$. Для шибко умных они называются не "делегаты" - мутантский термин для бывших-VB-программистов-окончивших-курсы - а замыкания(closures) или если еще более классически то lambda.
lambda как определение анонимной функции, и closures (функции,
связанные с лексическим окружением) - вещи, вообще говоря,
несвязанные.
* (let ((x 5)) (defun test-closure () (setf x (+ x 1))))
TEST-CLOSURE
* (test-closure)
6
* (test-closure)
7
Это замыкание.
а вот
my $coderef = sub {shift + 1};
это лямбда (ну, не совсем: аргументов нету). При этом она нифига не closure, если определена на верхнем уровне.
Я не знаю C#, но вроде как делегаты - это частный случай замыканий, в
которых вместо лексического окружения используется экземпляр класса.
Это гораздо больше похоже на function currying, чем на closure:
sub curry_first_arg($$) {
my $sub = shift;
my $arg = shift;
return sub {
$sub->($arg, @_);
}
}
package Some::Class;
sub new {
my $class = shift;
bless { callback => shift }, $class;
}
sub do_work() {
#...
$self->{callback}->($returned_data);
}
#some other code
1;
package Some::Class;
sub the_delegate {
my $self = shift;
my $param = shift;
#blah-blah
}
sub do_smth {
my $self = shift;
my $worker = new Some::Class(curry_first_arg(\&the_delegate, $self));
$worker->do_work();
# а вот здесь будет обратный вызов, эквивалентный
# $self->the_delegate($returned_data).
# причем worker class не обязан знать, что это метод, и чей это метод.
# например, мы могли бы "ре-делегировать", отдав туда делегата,
# которого нам самим дали снаружи.
}
> Ага. Только почему-то в 1.5 раза медленнее работает, чем 1.5
нифига подобного. при условии, что это промежуточные билды, скорость на 5+. Sun много сейчас делает по оптимизации библиотек. Swing в мустанге _очень_ шустрый. IDEA с ключом -Didea.no.jdk.check=true заработает.
На каком языке пример-то? Похож на Haskell, но вроде как не он. В нем, кажется да - но я его не знаю, не придумал, что же на нем имеет смысл писать нормальному человеку. Только обучающую книжку прочитал.
Но вообще-то, имхо, не обязана. Я чего-то не понимаю, или эта параметризация может "сломать" функциональную изоляцию: возвращаем из общего контекста список из двух функций: инкремент и декремент лексической переменной. Получается фигня.
>Я чего-то не понимаю, или эта параметризация может "сломать" функциональную изоляцию: возвращаем из общего контекста список из двух функций: инкремент и декремент лексической переменной. Получается фигня.
Дык такая фигня происходит с любым мутабельным объектом(здесь переменная). Не надо делать в функции side effect (типа setf) и все будет хорошо.
Если не вру то формально лямбда - это анонимная функция которая применяется к одному аргументу и окружению.
> Если не вру то формально лямбда - это анонимная функция которая применяется к одному аргументу и окружению.
Врешь, имхо. Нету никакого окружения. только оргумент.
В примере на хаскелле 10 - это просто value, не имеющая отношения к замыканиям и лексическому окружению (как scope перевести правильно?).
/me подумал, и понял, что в чисто-функциональных языках, коим является Haskell, замыканий быть не может вообще.
Все это не имеет ни малейшего отношения к java, в общем-то, кроме того, что closures - более гибкая штука, чем anonymous inner classes. Я, правда, не в курсе, есть ли языки, в которых замыкания бывают типизированными (в смысле, имеют статически типизированный список аргументов).
> Ну сделай на этой платформе БЫСТРЫЕ делегаты. Обломишься!
Да ёпта! На кой ляд мне твои делегаты? Зачем делать делегаты ради делегатов? Ну нету в яве делегатов, НЕТУ, но от их отсутствия никто особо не страдает (исключая тех, у кого на компьютере 10 разных операционных систем). Я же говорю, что не в языке дело, а вы мне опять про делегаты.
Ты туп неимоверно. Или это ПЛАТФОРМА, и тогда действительно "не в языке дело" - какую фичу языка захотим, такую и реализуем, или это язык с заточенной под него VM. Один единственный жалкий язык для недоумков - и тогда никто не смеет пасть разевать и вякать про какую-то там "платформу".
Платформа, это наверное питон, на нем и игры для мобил пишут уже, и для ПК, и веб-сайты, и поисковые машины, и софт для управления самолетами, и интерфейсы к базам данных и прочая, и прочая, и многая..... Ась?
А жабисты тока херней маются, мечтают о замыканиях и делегатах? Ась?
За "туп неимоверно" в реале получил бы по фейсу, козёл.
> ...какую фичу языка захотим, такую и реализуем...
за это тоже, потому что никак иначе невозможно объяснить, что "фичи" нахрен никому не сдались (или иначе, "фичи" имеют самый низкий приоритет при выборе языка). Люди (в отличие от "самых умных" упертых баранов) выбирают язык не из-за "фич", а из соображений быстрого и качественного выполнения поставленной задачи. Например математическое моделирование удобно делать в фортране, а писать серверные приложения в яве. Каким раком здесь стоят замыкания?
За "туп неимоверно" в реале получил бы по фейсу, козёл.
> ...какую фичу языка захотим, такую и реализуем...
за это тоже, потому что никак иначе невозможно объяснить, что "фичи" нахрен никому не сдались (или иначе, "фичи" имеют самый низкий приоритет при выборе языка). Люди (в отличие от "самых умных" упертых баранов) выбирают язык не из-за "фич", а из соображений быстрого и качественного выполнения поставленной задачи. Например математическое моделирование удобно делать в фортране, а писать серверные приложения в яве. Каким раком здесь стоят замыкания?
>> За "туп неимоверно" в реале получил бы по фейсу
> Ути-пути, какая смешная, жалкая шавка. Околей, пожалуйста, ничтожество.
> Ты просто упёртая и безграмотная мразь, и тебе, гниде, надо отрезать за это мудя.
Вот скажите мне, господа, как с такими людьми (люмпенами) можно общаться?