Здравствуйте, Dimonizhe, Вы писали:

D>Отсутствие знаний никого не красит. Смотреть Tapestry/JSF/Wicket
Ох. Попробуйте. Прочуствуете разницу.

Здравствуйте, mrozov, Вы писали:

M>1. Компактностью.

ну, право — несерьезно. учитывая то кол-во нажатий клавиш которое нужно в современных ИДЕ (к которым ВС с натягом относится). кроме того — анонимные классы функциональней, читабельней и вписываются в ОО.

M>2. Логичностью.

логичностью?? ссылка на метод это логично? даааа..

N>>вот и делегат.
M>воти оверхед
N>>позиция — давайте в язык пришащим все что сможем придумать мне тожне не нравится — получится помойка.
M>Именно. Хороший пример — анонимные классы.

как раз анонимные классы намного лучше столь любимых вами делегатов. как минимум — если нужно определить сразу 2-3-Н методов или завести локальную переменную. как с делегатом сделать такое?

interface A {
    int b();
    int c();
}

new A() {
    private int count;

    public int b() {
        return count++;
    }
    public int c() {
        return count--;
    }
}

вложенный класс делать?

M>С шаблонами — введение без изменения виртуальной машины. компромиссное решение. Тяжело уже в Java вводить что-то новое — по понятным причинам.

и что — какая разница как это сделано? зачем вообще ты вдаешься в подробность — изменилась ли виртуальная машина... чем на практике шаблоны плохо сделаны? зато байткод совместим, а в дотнете поди все библиотеки пересобирать пришлось?

а ДотНет легко вносить изменения потому что для него кода мало еще написано да и МС особенно о совместимости не думает — наколбасим а девелоперы пусть разбираются...

M>Понятно.

вот много кричат дотнетчики про то что АСП.НЕТ это наше все. но я так и не увидил ни одного аргумента в его пользу (хотя если спросить про то чем С# лучше заученно отвечают про делегаты). пожалуйста, расскадите про его уникальные фичи. очень интересно.

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Dimonizhe, Вы писали:

D>>Отсутствие знаний никого не красит. Смотреть Tapestry/JSF/Wicket
M>Ох. Попробуйте. Прочуствуете разницу.

У меня под боком сидят 4 дотнет программера. После долгих склок согласились, что в джаве есть но без визардов.

n0name2 wrote:

> и что — какая разница как это сделано? зачем вообще ты вдаешься в
> подробность — изменилась ли виртуальная машина... чем на практике
> шаблоны плохо сделаны? зато байткод совместим, а в дотнете поди все
> библиотеки пересобирать пришлось?

Байткод обратно несовместим. Прямая совместимость есть и в .NET и в Java.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Байткод обратно несовместим. Прямая совместимость есть и в .NET и в Java.

кстати, если способ байт код собранный под Java5 перенести под Java1.4. именно за счет того что шаблоны сделаны так а не иначе.
а в .NET можно сделать так (Java не умеет):

public static <T> T x() { return new T(); }

Здравствуйте, n0name2, Вы писали:

N>кстати, если способ байт код собранный под Java5 перенести под Java1.4. именно за счет того что шаблоны сделаны так а не иначе.
N>а в .NET можно сделать так (Java не умеет):

N>

N>public static <T> T x() { return new T(); }
N>

Можно так:

        public static T x<T>()
            where T : new()
        {
            return new T();
        }

Здравствуйте, anton_t, Вы писали:

S>>Если учесть, поверх чего работает .Net, то становится понятным, что .Net без хорошей поддержки нативного кода был бы просто не жилец. Так что гордиться такими вещами, как fixed и unsafe, на мой взгляд, довольно глупо. Они не от хорошией жизни были придуманы.

_>И поверх чего же работает .Net?

Как поверх чего? Поверх линуксов, макосов, фрибсдов да и майкрософтовских ос тоже...

Здравствуйте, n0name2, Вы писали:

N>как раз анонимные классы намного лучше столь любимых вами делегатов. как минимум — если нужно определить сразу 2-3-Н методов или завести локальную переменную. как с делегатом сделать такое?


N>

N>interface A {
N>    int b();
N>    int c();
N>}

N>new A() {
N>    private int count;

N>    public int b() {
N>        return count++;
N>    }
N>    public int c() {
N>        return count--;
N>    }
N>}
N>

очень просто. Вот допустим у нас был метод, куда мы собирались передавать твой анонимный класс:

public static void methodA(A ainstance);

вот так мы его вызывали ( я для компактности поменял выравнивание):

public static void test()
{
  methodA(
        new A()
        {
            private int count;

            public int b() { return count++; }
            public int c() { return count--; }
        }
    );
}

перепишем его на дотнет:

public delegate int A();
public static methodA(A b, A c);

и вызовем аналогичным твоему образом:

public static void Test()
{
    int count;
  methodA(
            delegate { return count++; }
            delegate { return count--; }
    );
}

Если есть еще вопросы — пиши, не стесняйся.
Встречный вопрос: как мне воспроизвести на Java вот это:

public static void Test()
{
  myObj.OnChange += delegate{ Console.Write("Hello, "); };
    myObj.OnChange += delegate{ Console.Write("world!"); };
}

Как там у нас насчет композиции интерфейсов?

Здравствуйте, Azix, Вы писали:

A>ВСЕ ЭТО РАБОТАЕТ

Если оно работает, то почему рекомендуют для запуска на моно компилировать именно компилерами от моно?

Здравствуйте, Sinclair, Вы писали:

S>и вызовем аналогичным твоему образом:
S>

S>public static void Test()
S>{
S>    int count;
S>  methodA(
S>            delegate { return count++; }
S>            delegate { return count--; }
S>    );
S>}
S>

S>Если есть еще вопросы — пиши, не стесняйся.

а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет? или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.

S>

S>public static void Test()
S>{
S>  myObj.OnChange += delegate{ Console.Write("Hello, "); };
S>    myObj.OnChange += delegate{ Console.Write("world!"); };
S>}
S>

S>Как там у нас насчет композиции интерфейсов?

ну да, неплохо. хотя если нужно такое то я бы уже начал аспектами пользоватся. такие тулзы под .НЕТ есть? AspectWerkz

Здравствуйте, mrozov, Вы писали:



M>С шаблонами — введение без изменения виртуальной машины. компромиссное решение. Тяжело уже в Java вводить что-то новое — по понятным причинам.

В смысле? Существует ~200 языков под джава байт-код.Такие конструкции НЕТ-у и не снились: например, после каждого вызова методов Set* (регулярное выражение) у классов com.custom.util.JDBC* (Еще регулярное выражение) сделать то-то (это из АОП)

Здравствуйте, n0name2, Вы писали:

N>Здравствуйте, Sinclair, Вы писали:

S>>и вызовем аналогичным твоему образом:
S>>

S>>public static void Test()
S>>{
S>>    int count;
S>>  methodA(
S>>            delegate { return count++; }
S>>            delegate { return count--; }
S>>    );
S>>}
S>>

S>>Если есть еще вопросы — пиши, не стесняйся.

N>а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет?
Ничего страшного. Конечно же, этот случай предусмотрен. Замыкание, как и в джаве, стянет count на себя. Фрейм Test ему не нужен.
N>или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.
Конечно же есть. Оно формируется неявно, захватывая те переменные из объемлющего scope, которые используются в анонимном делегате.
S>>

S>>public static void Test()
S>>{
S>>  myObj.OnChange += delegate{ Console.Write("Hello, "); };
S>>    myObj.OnChange += delegate{ Console.Write("world!"); };
S>>}
S>>

S>>Как там у нас насчет композиции интерфейсов?

N>ну да, неплохо. хотя если нужно такое то я бы уже начал аспектами пользоватся. такие тулзы под .НЕТ есть? AspectWerkz
Спокойствие, только спокойствие. Тулзы — они и в африке тулзы. Пока что мы говорим о том, для чего нужны "эти бесполезные делегаты, которые во всем проигрывают анонимным классам". Как видно, анонимные классы позволяют немножко точнее и многословнее описывать состояние делегата, зато у них нет встроенной поддержки Multicast. Еще одна маленькая фишечка анонимных делегатов — дотнет угадывает сигнатуру. Обратил внимание, что я не стал писать ни параметров, ни возвращаемого значения? Даже если у делегата есть входные параметры, но мой анонимный делегат их не использует (а это сплошь и рядом так для стандартных обработчиков событий — какой-нибудь Click очень редко требует анализа sender или args), я могу не писать (object sender, EventArgs args) между delegate и {}. Тип возвращаемого значения выводится из того, что возвращает return, а поскольку делегаты в дотнете контравариантны, то я могу возвращать объекты более точного типа, чем ожидается.
Таким образом, в простых случаях делегаты несколько удобнее. Если прибавить к ним поддержку событий, которые автоматически реализуют подписку/отписку, то джава начинает смотреться бледновато.

Здравствуйте, Sinclair, Вы писали:

S>Таким образом, в простых случаях делегаты несколько удобнее. Если прибавить к ним поддержку событий, которые автоматически реализуют подписку/отписку, то джава начинает смотреться бледновато.

короче убедил, в принципе действительно неплохая штука для всяких там OnClick, etc. в реальной жизни проекты на Жабе все больше используют IoC и собирают конечный код исходя из конфигурации заданной в аннотациях и отдельных файлах. все это позволяет довольно сильно снизить coupling и повысить расширяемость.

те кому в Жабном мире сильно нравятся всякие хитрые синтаксические фенечки давно перешли на Groovy. это такое расширение Жабы (код на чистой Жабе является подмножеством, даже плагины к IDE для него есть), позволяющего делать, например, следующее:

def xml = new NodeBuilder()
xml.customers() {
    loc = 'London'
    sql.eachRow("select * from customer where location = ${loc}) {

        // lets process each row by emitting some markup
        xml.customer(id:it.id, type:'Customer', foo:someVariable)) {
            role(it.person_role) 
            name(it.customer_name)
            location(id:it.location_id, name:it.location_name)
        }
    }
}

или так

Button b = new Button ("Push Me");
b.onClick { buttonClicked() }

def stringList = [ "java", "perl", "python", "ruby", "c#", "cobol",
                   "groovy", "jython", "smalltalk", "prolog", "m", "yacc"  ];

stringList.eachWithIndex() { obj, i -> println " ${i}: ${obj}" };

можно переопределять всякие там "+=" и делать композиции.. можно использовать одновременно жесткую типизацию и duck typing...

но лично мое мнение что синтаксические конструкции погоды не делают и при желании легко можно сделать расширение компилятора. гораздо большую роль играет наличие разнообразных библиотек, реализующих намного более нетривиальные вещи и возможность выбора реализации той или иной подсистемы исходя из нужд проекта (web server, application server, JVM, IDE, etc по соображениям цены/производительности/масштабируемости/управляемости и т.д.)

Здравствуйте, n0name2, Вы писали:

N>короче убедил, в принципе действительно неплохая штука для всяких там OnClick, etc.
Совершенно верно.
N>в реальной жизни проекты на Жабе все больше используют IoC и собирают конечный код исходя из конфигурации заданной в аннотациях и отдельных файлах. все это позволяет довольно сильно снизить coupling и повысить расширяемость.
Это тоже cool, хотя выглядит разочаровывающим для click-click anyhow developer, т.к. заставляет его думать о вещах, о которых он думать и не собирался. Я согласен с тем, что такое думание очень поможет на более далеких этапах развития как проекта, так и его разработчика. Но на старте внимание отвлекают как раз такие микровещи, упрощающие жизнь. Люди-то хотят прямо так нарисовать About Box, и сразу его увидеть. А не изучать, где в XML файле нужно написать строчку для Copyright, и в каком локализованном ресурсе указать action "About...", и где прописать Action Handler, и понять что надо использовать именно <ModalDialogHandler dlgId="AboutDlg"/>, чтоб потом напустить на это MegaUIPreCompiler, который выкинет набор шаблонов для кодогенератора, который сгенерирует набор классов для UI, и в качестве побочного эффекта мы получим команду About.. в меню Help. Которая зато также доступа в диалоге Customize для тулбаров, клавиатуры, и контекстных меню, автоматически дизаблится в тех случаях, когда команда недоступна, и даже умеет записываться в макрос. Cool. Где мой Hello world?
Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется

А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.

N>те кому в Жабном мире сильно нравятся всякие хитрые синтаксические фенечки давно перешли на Groovy. это такое расширение Жабы (код на чистой Жабе является подмножеством, даже плагины к IDE для него есть), позволяющего делать, например, следующее:
N>но лично мое мнение что синтаксические конструкции погоды не делают и при желании легко можно сделать расширение компилятора.
Это конечно же да — лишь бы за этим расширением стояла достаточная масса. Вот я, к примеру, с радостью и счастием возьму третий шарп на вооружение. А мегакомпилер от третьих фирм с теми же фичами, или даже большими — вряд ли. Потому как его дальнейшая судьба непредсказуема. Но в целом ты прав. К тому же дотнет прям-таки нарошно делался с прицелом на многоязычность. Я думаю, через пять лет мы просто будем по-быстрому ваять свое расширение шарпа под нужды конкретного проекта, и часть кода реализовывать на нем.
N>гораздо большую роль играет наличие разнообразных библиотек, реализующих намного более нетривиальные вещи и возможность выбора реализации той или иной подсистемы исходя из нужд проекта (web server, application server, JVM, IDE, etc по соображениям цены/производительности/масштабируемости/управляемости и т.д.)
Это да. Наличие фреймворка — великая вещь. Ну, тут меня греет светлое будущее. Пока что задачи, которые мы решаем, не требуют особых application server и прочих hi-end технологий. А небольшие технологии, вроде O/R Mapping уже в наличии есть. Для enterprize приложений конечно дотнет пока что выглядит тоненькой оберткой над неуправляемым миром, по сравнению с гигантами Java.

Здравствуйте, Sinclair, Вы писали:

S>Люди-то хотят прямо так нарисовать About Box, и сразу его увидеть.

ну так еще со времен дельфи/вб с этим особых проблем небыло. кстати, помню на дельфях мне и в голову не приходило использовать нечто вроде делегатов для обработки OnClick — вроде как ткнул в пропертиз и пиши код...

S>Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется

"не мы такие, жизнь такая..." (с) бумер

S>А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.

угу, мелочи а приятно. кстати, SQLJ (нечто вроде ЛИНКУ правда только для БД) уже был как-то в Жабе, почему-то не прижился, хотя эксгумировать можно...

S>Потому как его дальнейшая судьба непредсказуема.

вот это как раз одна из фундаментальных политик МС — юзай только наше и нишагу в сторону. мне она сильно не нравится. Сан себе такого не позволяет, иногда даже интегрирует сторонние продукты в core (например EJB3). бенчмарки новых процессоров (Niagara) публикует используя сторонний application server...

Здравствуйте, n0name2, Вы писали:

N>ну так еще со времен дельфи/вб с этим особых проблем небыло. кстати, помню на дельфях мне и в голову не приходило использовать нечто вроде делегатов для обработки OnClick — вроде как ткнул в пропертиз и пиши код...
Боюсь тебя разочаровать, но в дельфи как раз делегаты были с самого начала. Там не было поддержки мультикаста (что приходилось обходить через страшный геморрой — см. исходники TDataSource), но в целом очень похожая концепция. Фактически, делегат — это procedure of object на стероидах. Что, в общем-то, неудивительно, с учетом того, что у обеих фич один и тот же автор, только делегаты он сделал попозже.
S>>Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется

N>"не мы такие, жизнь такая..." (с) бумер

S>>А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.

N>угу, мелочи а приятно. кстати, SQLJ (нечто вроде ЛИНКУ правда только для БД) уже был как-то в Жабе, почему-то не прижился, хотя эксгумировать можно...

S>>Потому как его дальнейшая судьба непредсказуема.

N>вот это как раз одна из фундаментальных политик МС — юзай только наше и нишагу в сторону. мне она сильно не нравится.
Ничего подобного. Это моя личная политика. Просто я лично не очень жажду делать шаги в сторону. Хотя временами это напоминает необходимость иметь личный мерс, даже если твоя работа расположена на другой стороне той же улицы .
N>Сан себе такого не позволяет, иногда даже интегрирует сторонние продукты в core (например EJB3). бенчмарки новых процессоров (Niagara) публикует используя сторонний application server...
Сан себе не позволяет большинство из развлечений МС по единственной банальной причине: у них не так много денег. Время покажет, был ли прав Билли, или все это — вложения в очень длинную интерактивную игру для MS Research

Здравствуйте, Sinclair, Вы писали:

S>Сан себе не позволяет большинство из развлечений МС по единственной банальной причине: у них не так много денег. Время покажет, был ли прав Билли, или все это — вложения в очень длинную интерактивную игру для MS Research

зато "бедность" сама породила здоровую конкуренцию в результате которой было открыто множество стартапов, созданы многомиллиардные рынки разнообразного ПО и т.д.

лично я считаю что будующее за открытыми стандартами и опен сорсом потому что "сила не в деньгах, сила в правде" (с) брат. рано или поздно Билли придется отказатся от жесткого вендор локинга (отчасти в Висте он к этому уже идет) или придется потихоньку брести на кладбище. нельзя десятки лет с наглой рожей плевать на всех и вся...

многие монополии МС потихоньку сдают позиции открытому софту (офис, браузер, может быть даже винда). особенно большие надежды я возлагаю на Red Flag Linux ну и на AJAX... по большому счету столь высокая доля рынка во многом обеспечивается пиратами, что будет если, скажем, вендоры железа сделают аппаратную поддержку самоуничтожения компа в случае попытки установки пиратской программы ? думаю, очень многие (по крайней мере в РФ) кинутся ставить Линух.

Здравствуйте, n0name2, Вы писали:

S>>и вызовем аналогичным твоему образом:
S>>

S>>public static void Test()
S>>{
S>>    int count;
S>>  methodA(
S>>            delegate { return count++; }
S>>            delegate { return count--; }
S>>    );
S>>}
S>>

S>>Если есть еще вопросы — пиши, не стесняйся.

N>а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет? или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.

Hint: closures

Насколько я понял, count будет в данной ситуации выделен в куче (как поле специального класса) и делегат просто неявно получает ссылку на экземпляр этого класса. При каждом вызове Test будет создан новый такой объект (по сути, это просто контекст).

А вот в Java замыканий (нормальных, а не этого угрёбища с final-переменными, где они просто копируются при создании экземпляра анонимного класса) нет и пока вроде не предвидится. Что очень печально. Приходится городить тонны классов и интерфейсов, там, где казалось бы можно обойтись простыми лямбда-функциями.

S>>

S>>public static void Test()
S>>{
S>>  myObj.OnChange += delegate{ Console.Write("Hello, "); };
S>>    myObj.OnChange += delegate{ Console.Write("world!"); };
S>>}
S>>

S>>Как там у нас насчет композиции интерфейсов?

N>ну да, неплохо. хотя если нужно такое то я бы уже начал аспектами пользоватся. такие тулзы под .НЕТ есть? AspectWerkz

Вот-вот. Это и есть "подход Java". Там, где в приличных языках требуется пара строчек, в Java используются жуткие генераторы, инструментация байт-кода, монструозные технологии и прочая дребедень

Здравствуйте, WFrag, Вы писали:

WF>Вот-вот. Это и есть "подход Java". Там, где в приличных языках требуется пара строчек, в Java используются жуткие генераторы, инструментация байт-кода, монструозные технологии и прочая дребедень

Подход Жабы, что те кто надо используют "жуткие генераторы, инструментация байт-кода, монструозные технологии". А тем кому не надо — клиент-сайду например, не парятся с изучением конструкций нужных в 1% случаев.

Здравствуйте, Dimonizhe, Вы писали:

D>Подход Жабы, что те кто надо используют "жуткие генераторы, инструментация байт-кода, монструозные технологии". А тем кому не надо — клиент-сайду например, не парятся с изучением конструкций нужных в 1% случаев.

1%? Как считали? Мне функций высшего порядка и замыканий постоянно не хватает, хотя на "функциональных" языках я практически и не писал. А вот анонимные классы я редко использую, потому что мситаю, что они читабельность сильно ухудшают.