J2SE 1.5.0 переименован в J2SE 5.0

> Такие дженерики, как в яве, в .NET были всегда. Ничего же не мешает использовать шаблоны на managed C++.

Шаблоны на Managed C++, хоть и компилятся в CIL, но не являются .NET-совместимыми. То есть пользовать их можно только из такого же C++-кода, и опять же насколько мне известно без старых добрых #include'ов здесь не обойтись. Ну и зачем тогда вообще .NET?

> А вообще, давно поря признать, что .NET технологически совершеннее. Никакой крамолы в этом нет.

Давайте уточним: C# как язык - совершеннее (хотя, когда я увидел, как можно использовать inner-классы, у меня стали закрадываться сомнения по этому поводу)... пока что. Но судя по спецификациям - Java 1.5 будет как минимум на уровне C# 2.0. VM - да, совершенней, ибо лучше заточено под JIT. Сама платформа - очень сомнительно, достаточно вспомнить грубые ляпы в дизайне базовых классов, когда в качестве аргумента принимается не интерфейс, а _класс_ Array. ООП, млин... приехали. WinForms? рядом не стоял со SWING'ом и даже с SWT. ADO.NET? В целом неплохо, но зачастую еще многословней чем JDBC, что не есть хорошо. Ну и так далее...

> Что за ".NET 2.0 Beta"?

http://www.microsoft.com/downloads/details.aspx?FamilyId=F1232C37-0FEE-4AA6-A...

Thanks

> Соберите decl.cs в отдельную DLL-assembly, а потом уже test.cs со ссылкой на decl.dll. Вроде все замечательно...

Для таких случаев присваивай значения элементам. public enum Foo { First = 1 , Second = 2 }.

> Для таких случаев присваивай значения элементам. public enum Foo { First = 1 , Second = 2 }

Ну и чем это будет лучше нынешних жабских "public static final int ONE = 1, TWO = 2, ..."? Enum'ы - это высокоуровневый тип, и то, что в .NET их сделали просто другой инкарнацией int, по образу и подобию C, не говорит ничего хорошего о .NET...

> Ну и чем это будет лучше нынешних жабских

Ну и как ты передашь их всех в качестве параметра в функцию? Enum просто удобней в данном случае. Не надо возюкаться с массивами.

кстати...

> Во-первых, возможность ассоциировать с членами enum'а произвольные данные.

Что-то я такого там не увидел, в 1.5. Примерчик можно? Например со строками

> Ничего же не мешает использовать шаблоны на managed C++
Покажи кусок кода

> Хотя бы прикол с невозможностью написания на яве функции, которая переставляет местами два int'а.

Здесь поподробней плиз :-)

> Спорное утверждение. Я вот ничего такого "необъектноориентированного" не вижу в делегатах. Больше того, их можно рассматривать просто как syntactic sugar для anonymous inner классов, объявляемых вне методов.

Не разумно все делать объектно-ориентированным. Например, в яве существуют примитивные типы. Делегаты же - еще одно подтверждение, что кроме ООП существуют и другие полезные концепции.

Нафига вообще в жабе всякие enum ??? Используйте объекты - они рулез.

Ну, насколько я знаю, на Java нельзя написать функцию void swap(...);

int x,y; swap(x,y);

которая бы переставляла бы местами x и y, поскольку невозможно передать по ссылке примитивный тип. В .NET можно написть

void swap(ref int x,ref int y) { int t=x; x=y; y=t; }

>Шаблоны на Managed C++, хоть и компилятся в CIL, но не являются .NET-совместимыми

Это как? Может, имелось в виду не CLS-совместимые? Это да. Т.е. если интерфейс класса содержит какие-либо шаблонные классы, то использовать его можно только из С++. Но в реализации можно использовать шаблоны сколько угодно

>Давайте уточним: C# как язык - совершеннее

Свойства и перегрузка операций - это гуд

>VM - да, совершенней, ибо лучше заточено под JIT

Ну и плюс работа с разными языками. С тем же С++. Плюс возможность использовать неуправляемый код (что важно на первое время)

>Сама платформа - очень сомнительно, достаточно вспомнить грубые ляпы в дизайне базовых классов, когда в качестве аргумента принимается не интерфейс, а _класс_ Array

А какой интерфейс должен приниматься? А ещё масса методов принимают класс string. И что?

>WinForms? рядом не стоял со SWING'ом и даже с SWT Более чем спорное утверждение

>void swap(ref int x,ref int y) { int t=x; x=y; y=t; }

Да, это действительно круто :-) И главное это очень важная фича, которая мне еще ни разу не понадобилась. Более того, если _на_жабе_ возникает необходимость в таких фичах - ты просто не умеешь использовать ООП

>>А какой интерфейс должен приниматься? класс string. И что?
ICollection ?
>>А ещё масса методов принимают класс string
а другие int ...
(то же кстати прикольные ляпы насчет signed-unsigned
до сих пор не могу понять как может быть -1 элемент в коллекции
да и рассогласованность в размере типа представляещево размер коллекции ....)
framework производит впечатления "слегка недоделанного" - куча мелких ляпов
и со свойствами в рефлекшн они заблудились
и MSDN дописать до сих пор не успели, куча полупустых разделов
и .... не буду ныть
MS как всегда в своем репертуаре, много крика, много шума
а посмотреть - не плохо вроде, но вот бля, нормально подумать и сделать
уже духу не хватило,
и бабки вроде у конторы есть .....
для меня вершиной всего был CompactFramework

> void swap(ref int x,ref int y) { int t=x; x=y; y=t; }

> Да, это действительно круто :-) И главное это очень важная фича, которая мне еще ни разу не понадобилась. Более того, если _на_жабе_ возникает необходимость в таких фичах - ты просто не умеешь использовать ООП

Понимаешь, существует целый класс людей, воспринимающих любую невозможность сделать какое-нибудь сумасшедшее действие за недостаток. Что то типа: "Это ружьё не даёт мне выстрелить себе в ногу. Это неправильное ружьё!"

>>Давайте уточним: C# как язык - совершеннее

>Свойства и перегрузка операций - это гуд

Все это - весьма спорно...

В яве для свойств принято использовать getXXX(), setXXX() и isXXX(). Что касается библиотек .NET, то там в одних местах - свойства, в других - вызовы методов (типа System.Object.GetType() или GetHashCode()). В общем, разброд какой-то с этими свойствами...

Перегрузка операторов - хороша, пока используется по делу. А часто ли приходится создавать математические объекты с переопределенными арифметическими операциями?

---

>>Сама платформа - очень сомнительно, достаточно вспомнить грубые ляпы в дизайне базовых классов, когда в качестве аргумента принимается не интерфейс, а _класс_ Array

> А какой интерфейс должен приниматься? А ещё масса методов принимают класс string. И что?

Бозовых интерфейсов из System.Collections - несколько. Например, IEnumerable, ICollection, IList и т.д. Забавная фишка еще в том, что Array - класс, а не интерфейс, хотя он и реализует, кажысь, IList (сейчас сижу под линуксом - потому не могу быстро проверить).

Что касается string, то мне кажется, что в яве более разумный подход. Там где надо - StringBuffer, в остальных местах - просто String. Фактически, дот-нетовский string более похож на StringBuffer, чем на String.

---

>>WinForms? рядом не стоял со SWING'ом и даже с SWT

> Более чем спорное утверждение

Здесь могу согласится... Хотя, может быть, что-то и изменится с приходом J2SE 5.0 (Тигр).

> Ну и как ты передашь их всех в качестве параметра в функцию? Enum просто удобней в данном случае. Не надо возюкаться с массивами.

Вот именно что в .NET, enum - это слегка облагороженный int. Всего лишь. Но можно (и нужно) лучше.

>Такие дженерики, как в яве, в .NET были всегда. Ничего же не мешает >использовать шаблоны на managed C++.

Ухххх. Дружище, Вы что, хотите сравнить template'ы в C++ с generic'ами в Java ?

>Хотя бы прикол с невозможностью написания на яве функции, которая >переставляет местами два int'а.

Я конечно ничего не смыслю в Java, однако - например засуньте их в массив и меняйте наздоровье.

Captain.

> Вот именно что в .NET, enum - это слегка облагороженный int. Всего лишь. Но можно (и нужно) лучше.

Как и в яве. Поиграйся с этим кодом в 1.5

public class test {
  public static enum MainMenu {FILE, EDIT, FORMAT, VIEW};
		
  public static void main(String[] argv) {
		  System.out.println(MainMenu.FILE);
		  
		  java.lang.Class cl = MainMenu.FILE.getClass();
		  
		  System.out.println(cl.getName());
		  
		  Method[] xx  = cl.getMethods();
		  for ( int i = 0; i<xx.length; i++) {
				  Method cc = xx[i];
				  System.out.println(cc.getName());
		  }
  }
}

> Что-то я такого там не увидел, в 1.5. Примерчик можно? Например со строками

OT: Полез на java.sun.com - дожили... "This document covers the Java(tm) 2
Standard Edition 5.0 Development Kit (JDK 5.0). Its external version number is 5.0
and internal version number is 1.5.0."

А вообще пожалуйста, вот вам слегка видоизмененный пример из JSR:

public enum Coin {
    PENNY("one"), NICKEL("five"), DIME("ten"), QUARTER("twenty-five");

    Coin(String value) { this.value = value; }

    private final String value;

    public String value() { return value; }
}

public class CoinTest {
    public static void main(String[] args) {
        for (Coin c : Coin.values())
            System.out.println(c + ":\t" + c.value() +"¢");
   }
}

тобишь 5.0 :)

> А какой интерфейс должен приниматься?

IList или ICollection, в зависимости от того, что мы с ним делать собираемся.

> А ещё масса методов принимают класс string. И что?

String не реализовывает никаких интерфейсов, и потому нельзя написать ему замену. Здесь другое - вот оно хочет Array почему-то, а у меня все в ArrayList. В качестве примера, посмотрите на ICollection.CopyTo().

> > WinForms? рядом не стоял со SWING'ом и даже с SWT

> Более чем спорное утверждение

Хорошо, оспорьте. Или мне еще раз про отсутствие owner-drawn контролов вспомнить, для начала?

Вот еще более извращенное использование жабских enum'ов:

import java.util.*;

public abstract enum Operation {

    PLUS {
        double eval(double x, double y) { return x + y; }
    },

    MINUS {
        double eval(double x, double y) { return x - y; }
    },

    TIMES {
        double eval(double x, double y) { return x * y; }
    },

    DIVIDED_BY {
        double eval(double x, double y) { return x / y; }
    };

    // Perform the arithmetic operation represented by this constant
    abstract double eval(double x, double y);

    public static void main(String args[]) {
        double x = Double.parseDouble(args[0]);
        double y = Double.parseDouble(args[1]);
        for (Operation op : Operation.values())
            System.out.println(x + " " + op + " " + y + " = " + op.eval(x, y));
    }
}

> OT: Полез на java.sun.com - дожили...

А, понятно. То, что я смотрел - такого синтаксиса не показало http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/

Значение только класса не получишь. Если конечно не добавишь метод value()

> Как и в яве. Поиграйся с этим кодом в 1.5

Поигрался. И где там int? Окромя ordinal(), который является скорее хаком (для любителей таковых).
А вообще, напомню, нынешние жабские enum'ы - это просто syntactic sugar для соответствующего паттерна:

class MainMenu  {
  public static final MainMenu
        FILE = new MainMenu(),
        EDIT = new MainMenu(),
        FORMAT = new MainMenu(),
        VIEW = new MainMenu();

  private MainMenu() { }
}

Ну и плюс прикручена поддежка сериализации. Где тут int?

> А, понятно. То, что я смотрел - такого синтаксиса не показало

http://jcp.org/aboutJava/communityprocess/review/jsr201/index.html

> Значение только класса не получишь. Если конечно не добавишь метод value()

Я не совсем понял, это к чему? У членов enum'а нет значений, точнее, они сами по себе значения.

Насчёт свойств и методов доступа, то здесь логика простая. Свойство используется там, где логика тривиальна, а метод там, где могут потребоваться серьёзные вычисления. Собственно, ничего не мешает на C# реализовывать методы доступа, как в Java. Я уже не говорю про индексаторы. То же касается и перегрузки. Любой инструмент нужно использовать по уму. Но то, что возможность есть, это хорошо. Array, так же, как и String - специфичный класс. Поэтому и сделаны методы, принимающие именно класс, а не интерфейс. Вероятно, JIT может более оптимально обработать массив, нежели абстрактный ICollection.

Да, наличие у функции out-параметров - довольно важная фича.

> Поэтому и сделаны методы, принимающие именно класс, а не интерфейс. Вероятно, JIT может более оптимально обработать массив, нежели абстрактный ICollection.

_Типизированный_ array - да, разумеется. Но Array вообще - это просто класс с перегруженным индексатором (который он на самом деле берет из IList). Т.е. по скорости разницы между доступом через IList.this[] или через Array.this[] быть не должно.

> Да, наличие у функции out-параметров - довольно важная фича.

Иногда удобная, не спорю. Но без этой фичи прекрасно обходится масса языков - питон, например. Скажите, а вот кроме swap(), вам часто приходилось писать код на C# с out- и ref-параметрами?

Нет, не часто. Ну, может, если какую сортировку. Потому что когда нужно вернуть несколько значений, можно вернут массив. Предлагаю остановиться на формулировке "ref- и out- параметры полезная, в принципе, штука, но не необходимая".

Ну, информации о том, какой именно массив был использован для параметра, не было. одно дело

void f(string[] values) {...} а другое void f(array values) {...} В последнем случае это действительно выглядит не очень хорошо. И может быть оправдано, только если реализация существенным образом оптимизирована для работы с Array. Кстати, вспомнил ещё одну прикольную штуку, которая есть в C# - функции с произвольным числом аргументов. Понятно, что это просто синтаксическое удобство, но всё-таки.

> C# - функции с произвольным числом аргументов. Понятно, что это просто синтаксическое удобство, но всё-таки.

А вроде в пятое яве появилось тоже

> Но без этой фичи прекрасно обходится масса языков - питон, например

Да, но ведь в питоне есть кортежи и множественные присваивания!

x, y = y, x

Что может быть проще?

> Предлагаю остановиться на формулировке "ref- и out- параметры полезная, в принципе, штука, но не необходимая".

Согласен. Попутно предлагаю аналогично определить и inner classes, для паритета =)

> x, y = y, x

> Что может быть проще?

Это только swap. А прочие способы использования ref/out? Тут уже кортежи не помогут =)

> Хотя бы прикол с невозможностью написания на яве функции, которая
> переставляет местами два int'а.

На тему передачи примитивных типов по ссылке - 
если очень хочется, то можно:

...
public static void main(...)
{
   String str[] = new String[1];
   int i[] = new int[1];

   setPrimitiveValues(str, i);

   System..println(str[0] + " " + i[0]);
}


static void setPrimitiveValues(String[] str, int[] j)
{
   str[0] = "Byte my shiny metal ass";
   j[0] = 10000;
}
...

(Из книги "Java Pitfalls" (Michael C. Daconta, Eric Monk,..))

Согласен =)

> Ну, насколько я знаю, на Java нельзя написать функцию void swap(...); > int x,y; swap(x,y); > которая бы переставляла бы местами x и y, поскольку невозможно > передать по ссылке примитивный тип. В .NET можно написть > void swap(ref int x,ref int y) { int t=x; x=y; y=t; }

Используй Integer

И что это даст?

Согласен на счет логики выбора между свойством и методом. Но порою, приходится крепко призадуматься, а "что же между ними все-таки выбрать"? В случае Java выбора - нет, поэтому немного проще :) Вообще, излишние возможности языка - это не только благо, но и почти всегда потенциальное зло. Кто-то красиво сказал: "недостатки - это продолжение наших достоинств." Насчет Array. Я думаю, в подобных местах имеет место быть просчет разработчиков, от чего, кстати, никто из нас не застрахован. Скажем, для той же оптимизации под тип Array можно было бы воспользоваться простой "перегрузкой" метода или, в крайнем случае, проверять Runtime-тип объекта.

No pasaran. java.lang.Integer is unmutable:) Там нет XML^H^H^Hметода setValue.

> Используй Integer

у Integer нет метода setValue()

> No pasaran. java.lang.Integer is unmutable:) Там нет XML^H^H^Hметода setValue.

А где там сказано про java.lang.Integer? ;)


package org.int19h;

class Integer {
  ...
  void setValue(int value) { ... }
  ...
}

Вот кстати...

> java.lang.Integer is _unmutable_

Мне кажется, или оно все-таки immutable? ;) Потому как слово unmutable у меня вызывает ассоциации только с кнопкой mute/unmute в моем плеере =)

>ообще, излишние возможности языка - это не только благо, но и почти всегда потенциальное зло

Только вот всё равно все используют С++ :)

Вообще, преимущества С# над явой следующие: 1. Перегрузка операций 2. Свойства 3. Делегаты 4. Аргументы по ссылке 5. Функции с переменнымколичеством аргументов 6. Оператор foreach 7. Более разумная, на мой вгляд, политика разрешения имёнования классов (пространств имён).

Преимущества Java: 1. inner-классы. Которые, кстати, используются в основном для организации обработки событий, и при использовании делегатов потребность в них возникает редко.

Поскольку мы тут говорим о 1.5, то бишь уже 5.0, то foreach и varargs в нем фигурируют. Сокращайте списочек =) А насчет inner-классов, так это можно и наоборот сказать: "при использовании inner-классов потребность в делегатах не возникает" ;)

Свойства - приятная фича, и их поддержка на уровне языка (без костылей в виде beans) радует, но не более того. Принципиально они ничего не дают. Перегрузка операторов - аналогично, считать что-то зубодробительное на яве вряд ли разумно, а так помимо BigInteger и BigNumber их и использовать-то особо негде. Аргументы по ссылке - уже обсудили =) Насчет пространств имен я, честно говоря, не понял - чем они принципиально отличаются от пакаджей?

> 1. Перегрузка операций

Причина огромного количества граблей в С++ коде. Вряд ли это лучше в С#. Очень благодарен жабе, что этого там нет.

> 2. Свойства

Реально, это перекликается с перезагрузкой операторов. Тот же синтаксический сахар, те же потенциальный грабли.

> 3. Делегаты

Не нужны при наличии анонимных внутренних классов

> 4. Аргументы по ссылке

Да, иногда не хватает. Но в 90% случаев лечится аккуратным проектированием.

> 5. Функции с переменнымколичеством аргументов

Да, хорошо бы...

> 6. Оператор foreach

Уже. В 5.0

> 7. Более разумная, на мой вгляд, политика разрешения имёнования классов (пространств имён).

Можно подробнее?