Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 17.06.04 07:26
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

НРA>Статья:



НРA>Авторы:

НРA> Ноздреватых Ростислав aka Blazkowicz

НРA>Аннотация:

НРA>Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будут рассмотрены основные из них.

Интересно, как были переведены термины
generics (в отношении не только классов, но и методов)
type parameter
generic method
wildcard

PS
К сожалению, статью в журнале не читал.
--
Дмитро
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 17.06.04 08:00
Оценка: 1 (1)
Здравствуйте, dshe, Вы писали:

D>Интересно, как были переведены термины

D>generics (в отношении не только классов, но и методов)
D>type parameter
D>generic method
D>wildcard

Да в общем не мудрствовал сильно. Шаблоны классов, методов. wildcard можно перевести как маска.
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 10:44
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 12.10.04 10:46
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


Извиняюсь не силен в генериках, что значит "параметризированнное наследование"?
Re[5]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 10:54
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

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


B>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


B>Извиняюсь не силен в генериках, что значит "параметризированнное наследование"?


Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


template<typename T>
struct A : public T
{
//bla bla
};

//а еще так
template<template<class> class T>
struct A: public T<A>
{
//bla bla
};
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 12.10.04 10:58
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


B>
B>template<typename T>
B>struct A : public T
B>{
B>//bla bla
B>};

B>//а еще так
B>template<template<class> class T>
B>struct A: public T<A>
B>{
B>//bla bla
B>};

B>


А для тех кто в танке можно по русски что требуется? Я просто на плюсах писал в далёком студентчестве без всяких шаблонов. И такой код для меня полная загадка.
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:13
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

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


B>>Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


B>>
B>>template<typename T>
B>>struct A : public T
B>>{
B>>//bla bla
B>>};

B>>//а еще так
B>>template<template<class> class T>
B>>struct A: public T<A>
B>>{
B>>//bla bla
B>>};

B>>


B> А для тех кто в танке можно по русски что требуется? Я просто на плюсах писал в далёком студентчестве без всяких шаблонов. И такой код для меня полная загадка.


Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 11:19
Оценка:
Здравствуйте, Batiskaf, Вы писали:

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


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


B>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


Нет. Не разрешено.
--
Дмитро
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:23
Оценка:
Здравствуйте, Batiskaf, Вы писали:


B>Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.


Пожалуй стоит проилюстрировать ( псевдо код ):


struct Person
{
   void SetName(string name){}
};

struct Product
{
   void SetName(string name) {}
};

template< typename T >
struct CheckNameLength : public T
{
  void SetName(string name)
  {
    if( name.length() > 0 )
      T::SetName(name);
    else
      throw ZerroLengthError(...);
  }
};

CheckNameLength<Person> vasya;
vasya.SetName("Vasya");
CheckNameLength<Product> windowsXP;
windowsXP.SetName("Windows XP");
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:24
Оценка:
Здравствуйте, Batiskaf, Вы писали:


B>Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.


Пожалуй стоит проилюстрировать ( псевдо код ):


struct Person
{
   void SetName(string name){}
};

struct Product
{
   void SetName(string name) {}
};

template< typename T >
struct CheckNameLength : public T
{
  void SetName(string name)
  {
    if( name.length() > 0 )
      T::SetName(name);
    else
      throw ZerroLengthError(...);
  }
};

CheckNameLength<Person> vasya;
vasya.SetName("Vasya");
CheckNameLength<Product> windowsXP;
windowsXP.SetName("Windows XP");
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:42
Оценка:
Здравствуйте, dshe, Вы писали:

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


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


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


B>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>Нет. Не разрешено.


Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.

Ну а метаданные к примеру, можно ли например соорудить на этой фишке что то типа аспектов, что бы управление передавалось в метод анотации, типа если анотация присвоена члену класса то вызвать сначала метод анотации, которая с параметром чего то проделает а потом передать члену класса, тоже самое можно и в отношении методов класса делать, собственно тоже самое, что можно уже сегодня делать темплейтами на плюсах.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 13:00
Оценка: 5 (1)
Здравствуйте, Batiskaf, Вы писали:

B>>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>>Нет. Не разрешено.


B>Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.


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


Снова нет. Для аспектов существует AspectJ.

Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

Кстати, существовало довольно много реализаций генериков на Java. Наиболее известные: PolyJ, NextGen, GJ. Tiger происходит главным образом от GJ.

Вот, может быть, будет интересна эта ссылка:
Java Generics: Final Report
--
Дмитро
Re[9]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 13:38
Оценка:
Здравствуйте, dshe, Вы писали:

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


B>>>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>>>Нет. Не разрешено.


B>>Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.


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


D>Снова нет. Для аспектов существует AspectJ.


А в одном флаконе можно? : Странно как то, хочется использовать продвинутые парадигмы программинга, а тебе предлагают типизированный вектор построить, сиди и не выступай Вот из-за таких вещей я не долюбливаю джаву, сколько лет кричали что как здорово что появилась джава, в ней все гораздо проще, и даже этих ужастных темплейтов нету, а когда разобрались наконец что без таких мега средств сегодян нельзя то выдали блин...

D>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

D>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс. А если же джава и вовсе их компилирует на в байт код во время основной компиляции то тогда не вижу причины упрощать параметризирование, разработай нормальную диагностику ошибок и дай людям полноценный инструмент.

D>Кстати, существовало довольно много реализаций генериков на Java. Наиболее известные: PolyJ, NextGen, GJ. Tiger происходит главным образом от GJ.


D>Вот, может быть, будет интересна эта ссылка:

D>Java Generics: Final Report
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[10]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 14:31
Оценка:
Здравствуйте, Batiskaf, Вы писали:

D>>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

B>Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

Я не думаю, что без ограниченного параметризма можно удовлетворительно диагностировать ошибки.
Java не позволит откомпилировать такой класс:
public class Sample {
     <T> boolean less(T a, T b) {
          return (a.compareTo(b) < 0);
     }
}

потому, что компилятор не знает откуда взялось compareTo и как его вызвать. А вот так
public class Sample {
     <T extends Comparable<T>> boolean less(T a, T b) {
          return (a.compareTo(b) < 0);
     }
}

очень даже откомпилируется. И для VM этот класс будет выглядеть приблизительно так:
public class Sample {
     boolean less(Comparable a, Comparable b) {
          return (a.compareTo(b) < 0);
     }
}

И этот самый код будет использоваться и для Sample.less<Integer>, и для Sample.less<String>. А вот Sample.less<Thread> вызовет ошибку компиляции поскольку Thread не реализует интерфейс Comparable<Thread>. И эта ошибка внятно об этом сообщит. Причем (это важно отметить!) компилятор будет руководствоваться исключительно декларацией метода, а не тем, как же этот метод внутри реализован.

В C++ же каждая новая инстанция шаблона компилируется "заново", что приводит во-первых к code bloat, а во-вторых, к тому, что в случае неправильного использования шаблона (параметризации его неверным типом) компилятор в состоянии только указать на то, что же именно в недрах шаблонного класса ему не понравилось, вынуждая тем самым программиста, который использует данный шаблонный класс, разбираться в его реализации. (Конечно, в C++ существуют приемы, которые позволяют "ограничивать" параметры шаблонов. Однако, поскольку это не является частью языка, разработчики шаблонов могут ими не пользоваться или ошибаться -- т.е. не указывать все ограничения.)

D>>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

B>Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс.

В .NET идет генерация кода только для value-типов (object-типы разделяют общий код). В С++ отдельный код создается для каждой инстанции шаблона.
--
Дмитро
Re[11]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 15:13
Оценка:
Здравствуйте, dshe, Вы писали:

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


D>>>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

B>>Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

D>Я не думаю, что без ограниченного параметризма можно удовлетворительно диагностировать ошибки.

D>Java не позволит откомпилировать такой класс:
D>
D>public class Sample {
D>     <T> boolean less(T a, T b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>потому, что компилятор не знает откуда взялось compareTo и как его вызвать. А вот так
D>
D>public class Sample {
D>     <T extends Comparable<T>> boolean less(T a, T b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>очень даже откомпилируется. И для VM этот класс будет выглядеть приблизительно так:
D>
D>public class Sample {
D>     boolean less(Comparable a, Comparable b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>И этот самый код будет использоваться и для Sample.less<Integer>, и для Sample.less<String>. А вот Sample.less<Thread> вызовет ошибку компиляции поскольку Thread не реализует интерфейс Comparable<Thread>. И эта ошибка внятно об этом сообщит. Причем (это важно отметить!) компилятор будет руководствоваться исключительно декларацией метода, а не тем, как же этот метод внутри реализован.
Ну так пиши себе Comparable, зачем тебе параметризировать шаблоном, который сводится к тупому варианту Если уж javac.exe бежит, то в случае явного инстанцирования метода можно заглянуть в прототип класса, который опускается в less, и понять что метода такого не существует. Какая разница между двумя строчками:

public class Sample {
     <T> boolean less(T a, T b) {
          return (a.Fuck(b) < 0);
     }
}

void main(...)
{
   string str1 = "str1";
   string str2 = "str2";
   Sample s = new Sample();
   s.less(str1, str2 );

   str2.Fuck(); // почему компилятор в состоянии понять что метод не сущестует в интерфейсе класса, а в случае less не желает этого проверять и предпочитает обезопаситься??
}



D>В C++ же каждая новая инстанция шаблона компилируется "заново", что приводит во-первых к code bloat, а во-вторых, к тому, что в случае неправильного использования шаблона (параметризации его неверным типом) компилятор в состоянии только указать на то, что же именно в недрах шаблонного класса ему не понравилось, вынуждая тем самым программиста, который использует данный шаблонный класс, разбираться в его реализации. (Конечно, в C++ существуют приемы, которые позволяют "ограничивать" параметры шаблонов. Однако, поскольку это не является частью языка, разработчики шаблонов могут ими не пользоваться или ошибаться -- т.е. не указывать все ограничения.)

Ну так в том примере не компилируется заново потому что только одна версия и генерится, только какой прикол тогда использовать генерики, пиши себе Comparable, такое и в плюсах делать можно, только никакой гибкости. Мало того что в джаве нет перегрузки операторов, так еще и параметры нужно ограничивать, очень примитивные средства. А те вещи, о которых я говорю на самом деле должны компилироваться по новой, потому что речь идет о более высшей модульности темплейтных компонент, мне все равно сколько кода нагенерится для решения этой задачи, лучше пусть компилятор нагенерит, нежели я руками буду сам это генерить. И еще одна причина раздутого кода, это инлайн, практически всесь СТЛ инлайнится, чем и обусловлена хорошая производительность контейнеров их этой библиотеки, напиши свои контейнеры без инлайна и размер выходного файла существенно сократится, только проиграет производительность.



D>>>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

B>>Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс.

D>В .NET идет генерация кода только для value-типов (object-типы разделяют общий код). В С++ отдельный код создается для каждой инстанции шаблона.


Возможно что я многих расстрою, но на рынке появляются уже С++ компиляторы, которые пошли еще дальше чем дот нет:


std::vector<int>;
std::vector<long>;


код для этих двух разных векторов будет общим, в этом направлении очень много потенциала для оптимизации, это только начало. Что касается параметризирования контейнеров указателями разных типов, то многие компиляторы уже давно справляются с этой ситуацией и генерят только одну специализацию вектора на всех типов указателей.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 13.10.04 21:43
Оценка: +2
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

Выскажу своё эмоциональное мнение и философский взгляд на вещи.

Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).

Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.

Не множьте сущности без необходимости! (Как сказал один мудрец)
Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!
Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?
Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Да, размер исходного кода уменьшился значительно, но что взамен?
1. ВЫРОСЛА СЛОЖНОСТЬ КОМПИЛЯТОРА (он защищён от ошибок? для C++ компилятор писали годами...но не избавились от неоднозначностей до сих пор);
2. ВЫРОС ПОРОГ ПОНИМАНИЯ КОДА ЧЕЛОВЕКОМ (теперь необходимо знать (о ужас!) шаблоны и дженерики, от которых отказались вначале для простоты);
3. ВЫРОСЛО ЧИСЛО ДУБЛИРУЮЩИХ СУЩНОСТЕЙ, отравляющих жизнь вопросами выбора, — налицо потребительский подход к решению задач.

В общем, после версии 1.1.8 Java стала сложнее, а с выходом версии 1.5 язык потерял, наконец-то, всю прелесть простоты. От чего хотели уйти, к тому же и пришли — круг замкнулся.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 14.10.04 07:35
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Выскажу своё эмоциональное мнение и философский взгляд на вещи.


ZEN>Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).


Ну не знаю. Для меня это не та причина по которой можно не любить генерики.

ZEN>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.


А по-моему прикольно. Я уже привык и часто пользуюсь.

ZEN>Не множьте сущности без необходимости! (Как сказал один мудрец)

ZEN>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!
ZEN>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?
ZEN>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
ZEN>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Вот такое есть. Новичков особенно запутывает.

ZEN>Да, размер исходного кода уменьшился значительно, но что взамен?

ZEN>1. ВЫРОСЛА СЛОЖНОСТЬ КОМПИЛЯТОРА (он защищён от ошибок? для C++ компилятор писали годами...но не избавились от неоднозначностей до сих пор);
Да, по-моему не сильно. Накрутили на него сторонние проекты и всего-то делов.

ZEN>2. ВЫРОС ПОРОГ ПОНИМАНИЯ КОДА ЧЕЛОВЕКОМ (теперь необходимо знать (о ужас!) шаблоны и дженерики, от которых отказались вначале для простоты);

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

ZEN>3. ВЫРОСЛО ЧИСЛО ДУБЛИРУЮЩИХ СУЩНОСТЕЙ, отравляющих жизнь вопросами выбора, — налицо потребительский подход к решению задач.

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

То есть к примеру если вы издаёте журнал, то нельзя позволять читателю влиять на его дизайн. Нужно просто делать хороший дизайн. Тут ты на 100% прав.

ZEN>В общем, после версии 1.1.8 Java стала сложнее, а с выходом версии 1.5 язык потерял, наконец-то, всю прелесть простоты. От чего хотели уйти, к тому же и пришли — круг замкнулся.


Угу. Особенно меня раздражает в работе Sun не то что делается, а как. Такое ощущение что они идут по пути наименьшего сопротивления. Как бы побыстрее и попроще сделать, а на сколько хорошо в итоге получиться.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 14.10.04 08:33
Оценка: 1 (1)
Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:


ZEN>Выскажу своё эмоциональное мнение и философский взгляд на вещи.


ZEN>Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).


ZEN>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.


Ну так это же основная фишка в event handling в джава апликациях, потому как замыкания в джаве не придумали, и множественного наследования тоже нет, вам ли этого не знать!!?? Почему нельзя создать инстанс иннер класса вне класса внешнего, или даже в статическом методе внешнего класса, вы хоть задумывались??? Потому что при создании экземпляра в него в неявной форме передается ссылка на текущий экземпляр внешнего класса, эту ссылку руками передавать не нужно, фишка встроена в язык, тогда из метода иннер класса можно достукиваться к членам внешнего класса по такой конструкции:


public class Class1
{
    public Class1()
    {
    }
    private void F1()
    {
        System.out.println( "Class1::F1" );
    }

    public class Callback
    {
        public void F1()
        {
            System.out.println( "Class1::Callback::F1" );
            Class1.this.F1();//Специально для удобства программистов!!!
        }
    }

    Callback GetCallback()
    {
        return new Callback();
    }

    public static void main(String[] args)
    {
        Class1 obj = new Class1();
        Callback clb = obj.GetCallback();
        clb.F1();
    }
}


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

ZEN>Не множьте сущности без необходимости! (Как сказал один мудрец)

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

ZEN>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!

Мне кажется все вполне логично, обычный стринг предназначен для хранения, передачи, легких модификаций, в билдере упор делается на удобный интерфейс построения, конкатинации стрингов, частых массивных модификаций, с более адаптированными под такие вещи стратегиями памяти. Такие вещи не возникают на прямом месте, вот просто так программисты ковыряли в носу и выдумали класс, рождение этого класса стало заключением некоторого опыта, частных решений специфических проблем, неважными результатами профилировки приложений. Насколько я понимаю стринг билдер это далеко не коллекция, это контейнер, но со своими, заточенными под определенные операции средствами.



ZEN>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?

ZEN>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
ZEN>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Процитирую себя же: "Реальный мир гораздо сложнее того парника, который выдумывают себе люди".
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 15.10.04 09:17
Оценка:
Здравствуйте, Batiskaf, Вы писали:

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

iZEN>>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.

B>Ну так это же основная фишка в event handling в джава апликациях, потому как замыкания в джаве не придумали, и множественного наследования тоже нет

Интерфейсы моделируют множественное наследование не хуже. В редких случаях, правда, приходится обходить одинаковые сигнатуры.
А вот Event-обработка (Паттерн Observer, очевидно) может работать БЕЗ внутренних классов.
Что касается излишней "доступности" классов-обработчиков (Adaptee), то это спорный вопрос (а может в будущем понадобится делать отдельную ветку наследования обработчиков — с внутренними классами это получится не очень красиво).

B>Почему нельзя создать инстанс иннер класса вне класса внешнего<...>

<...>
B>Таким образом калбэк класс может имплементировать методы какого то ивент адаптера ( внешний класс не может этого сделать, потому как нет множественного наследования, он наследует к примеру бизнес логику предметной области, остается только наследоваться от интерфейсов, что не всегда удобно и муторно ). Таким же макаром в общем случае можно имитировать множественное наследование.
Это понятно.
Но сложности перекладываются на компилятор (Сейчас вообще — монстрина). Это мешает развиваться сторонним компиляторам, которые вынуждены копировать всё больше "особенностей" (если такие есть, ведь C++ компилер до сих пор неоднозначен) оригинального Sun-овского.

iZEN>>Не множьте сущности без необходимости! (Как сказал один мудрец)

B>Реальный мир гораздо сложнее того парника, который выдумывают себе люди.

iZEN>>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!

B>Мне кажется все вполне логично, обычный стринг предназначен для хранения, передачи, легких модификаций, в билдере упор делается на удобный интерфейс построения, конкатинации стрингов, частых массивных модификаций, с более адаптированными под такие вещи стратегиями памяти. Такие вещи не возникают на прямом месте, вот просто так программисты ковыряли в носу и выдумали класс, рождение этого класса стало заключением некоторого опыта, частных решений специфических проблем, неважными результатами профилировки приложений. Насколько я понимаю стринг билдер это далеко не коллекция, это контейнер, но со своими, заточенными под определенные операции средствами.
Стратегия памяти не должна показывать свои уши в прикладном коде вообще — это касается LinkedList и ArrayList. Рантайм должен сам на лету определять, что куда быстро перемещается, и реагировать на это изменением стратегии планирования/распределения ресурсов.
В Java2 сделали всё наоборот: переложили на прикладной код системные вещи (BufferedStream-ы — типичная системная особенность) — это нужно было делать в нативной среде рантайма, а для Java-программиста оставить простые потоки, читалки, писалки и т.д.

iZEN>>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?

iZEN>>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
iZEN>>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

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

Так легче создать "парник" и сидеть там, чем колбаситься в этом дер...ом мире.
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: mselez  
Дата: 28.10.04 18:51
Оценка:
Вот тут дисскуссии все о высоком.
Мы попробовали проект перевести на 1.5 . И сразу облом.

Уже не работает так:

StringBuffer buf = new StringBuffer();
buf.append(1.0f).append("kuku").append...


а работает так

StringBuffer buf = new StringBuffer();
buf.append(1.0f);//здесь возвращается AbstractStringBuilder
buf.append("kuku");
buf.append...


догадываюсь, что это только начало.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.