static class A
{
}
static class B extends A
{
}
public static void main(String[] args)
{
A[] a = new B[4];
a[0] = new B();
a[1] = new A(); // ошибка
}
Несколько мыслей о будущем Java и не только (навеяно разными недавними обсуждениями)
Захотелось сделать предварительный вброс для небольшого холивара.
Недавно обсуждались темы для будущих подкастов Радио-Т, кстати сами подкасты бывают иногда интересны, могу даже порекомендовать.
И среди прочих всплыла тема о будущем Java как языка, и как платформы.
Если вкратце - что могут сделать рулевые Java, чтобы удержать ее на плаву в течении долгого времени. Вот тут обсуждение пошло в сторону того, почему в лабораториях Microsoft Research более или менее активно разрабатываются альтернативные языки для платформы .NET (такие, например, как F#), а вот Sun/Oracle с такой поддержкой альтернативным языкам отстают.
А тут я сам написал небольшой пост по этому поводу.
Да и вообще, заметна разница в позиционировании платформ. .NET изначально позиционировался как платформа для скрещивания в рантайме многих языков (для начача это были C#, VB#, managed C++), а вот у маркетологов Java такого заметно не было. Всегда шло позиционирование немного другое - Java это такой универсальный язык, который работает на платформе Java, где есть платформенно-независимый байткод, нет работы с памятью и прочего. Но вот про то, что под JVM можно разрабатывать и портировать другие языки, и писать код на них - на это особого упора, сколько я помню, никогда не делалось.
Так кто все же что думает по этому поводу? Будущее - за языками, как таковыми, в их теперешнем понимании (включая такие языки как Lisp, Nemerle, Ruby...), или все же за платформами для хостинга рантайм-сервисов, с кучей компиляторов под них (которые по сути, парсеры грамматики и генераторы байкода в том или ином виде).
Недавно обсуждались темы для будущих подкастов Радио-Т, кстати сами подкасты бывают иногда интересны, могу даже порекомендовать.
И среди прочих всплыла тема о будущем Java как языка, и как платформы.
Если вкратце - что могут сделать рулевые Java, чтобы удержать ее на плаву в течении долгого времени. Вот тут обсуждение пошло в сторону того, почему в лабораториях Microsoft Research более или менее активно разрабатываются альтернативные языки для платформы .NET (такие, например, как F#), а вот Sun/Oracle с такой поддержкой альтернативным языкам отстают.
А тут я сам написал небольшой пост по этому поводу.
Да и вообще, заметна разница в позиционировании платформ. .NET изначально позиционировался как платформа для скрещивания в рантайме многих языков (для начача это были C#, VB#, managed C++), а вот у маркетологов Java такого заметно не было. Всегда шло позиционирование немного другое - Java это такой универсальный язык, который работает на платформе Java, где есть платформенно-независимый байткод, нет работы с памятью и прочего. Но вот про то, что под JVM можно разрабатывать и портировать другие языки, и писать код на них - на это особого упора, сколько я помню, никогда не делалось.
Так кто все же что думает по этому поводу? Будущее - за языками, как таковыми, в их теперешнем понимании (включая такие языки как Lisp, Nemerle, Ruby...), или все же за платформами для хостинга рантайм-сервисов, с кучей компиляторов под них (которые по сути, парсеры грамматики и генераторы байкода в том или ином виде).
Цитата: Zorkus
Да и вообще, заметна разница в позиционировании платформ. .NET изначально позиционировался как платформа для скрещивания в рантайме многих языков (для начача это были C#, VB#, managed C++)
Я всегда с недоверием относился к этой позиции. Уж слишком похожими на C# выглядели все эти VB, Delphi и прочие порты на .NET. Хотя MC++ несколько выбивается из этого ряда своей шизофренической системой типов, но зато он такой один. :D
Цитата: Zorkus
Так кто все же что думает по этому поводу? Будущее - за языками, как таковыми, в их теперешнем понимании (включая такие языки как Lisp, Nemerle, Ruby...), или все же за платформами для хостинга рантайм-сервисов, с кучей компиляторов под них (которые по сути, парсеры грамматики и генераторы байкода в том или ином виде).
А мне видится будущее за системами типов как средствами контроля корректности программ. ФП уже прорвалось в мейнстрим языки, глядишь, и размеченные объединения появятся.
ПС. CLR ничем принципиально не лучше JVM. Микрософт сумел в нее пачку фундаментальных ошибок засадить, основные: ковариантность массивов (привет Java!), именованные функциональные типы (делегаты), CAS и т.д.
Цитата: hardcase
ковариантность массивов (привет Java!)
Ето наезд?
Java в етом плане безопасна с точностю до неконтролированого ексепшена в момент присвоение значения елементу масива.
Код:
Цитата: Rebbit
Ето наезд?
Java в етом плане безопасна с точностю до неконтролированого ексепшена в момент присвоение значения елементу масива.[/code]
Java в етом плане безопасна с точностю до неконтролированого ексепшена в момент присвоение значения елементу масива.[/code]
Кто-то недавно говорил про "проверку типов ушедшую на мороз"...
Ковариантные мутабельные структуры данных - это дебилизм, пример, демонстрирующий это, ты сам же и привел.
Цитата: hardcase
Кто-то недавно говорил про "проверку типов ушедшую на мороз"...
И что. Я что говорил что ето плохо? Нет. Я вообще JS обожаю за отсутствие ограничений.
Цитата: hardcase
Ковариантные мутабельные структуры данных - это дебилизм, пример, демонстрирующий это, ты сам же и привел.
Дебилизм ето юзать инструмент для неправильных целей.
Создавать масив в одном месте, а заполнять в другом в данном случае не очень хорошо. А почитать в другом месте елементы базового типа.... чем плохо.
Не ставте себе лишних ограничений навеяних модой и лишних правил что есть правильно, а что неправильно. Заполнять масив тоже можно где угодно если делать ето с умом. Делайте так чтоб было удобно, а не "правильно".
Цитата: Rebbit
Делайте так чтоб было удобно, а не "правильно".
Это вопрос здравого смысла. Зачем ковариантность мутабельной структуре данных. Объясни пожалуйста и обоснуй. В моей практике я не могу вспомнить ни единого случая, когда мне потребовалось бы сделать что-то вроде:
Код:
string[] x = ...;
object[] y = x;
object[] y = x;
Цитата: hardcase
Это вопрос здравого смысла. Зачем ковариантность мутабельной структуре данных. Объясни пожалуйста и обоснуй. В моей практике я не могу вспомнить ни единого случая, когда мне потребовалось бы сделать что-то вроде:
Код:
string[] x = ...;
object[] y = x;
object[] y = x;
Функция сортирующая масив обектов по определенному компаратору
Цитата: Rebbit
Функция сортирующая масив обектов по определенному компаратору
Отлично, в .NET есть строго типизированное решение (в классе System.Array):
Код:
void Sort<T>(T[] array, Comparer<T> comparer);
Comparer<T> - делегат.
Это решение работает даже со структурами, для которых ковариантность не работает. Мысль на этот счет: Микрософт бездумно скопировал нехорошее решение из Java вселенной (CLR 1.0 в сущности и была клоном JVM, генерики они тогда не успели сделать).
Ну и? Всеровно в момент компиляции будет массив базового типа. Единственное чем ето безопаснее - невозможно создать инстанс Т (почти невозможно).
А у дженериков есть своя почка подводних камней. И они ой как неприятны.
А у дженериков есть своя почка подводних камней. И они ой как неприятны.
Цитата: Rebbit
Всеровно в момент компиляции будет массив базового типа
Нет. Будет тип массива заданный при его создании.
Цитата: Rebbit
Единственное чем ето безопаснее - невозможно создать инстанс Т (почти невозможно).
Создать можно. Как штатно, используя ограничение new(), так и нештатно (в обоих случаях используется класс Activator). И все же запретив ковариантность массивов мы избавляем CLR от необходимости проверять тип при присваивании значений элементам массивов (и следовательно от необходимости удалять эту проверку, где не требуется, при JIT-компиляции).
Цитата: Rebbit
А у дженериков есть своя почка подводних камней. И они ой как неприятны.
Давай, выкладывай :)
Цитата: hardcase
Давай, выкладывай :)
Я про .НЕТ говорить не буду так как давно его в руках не держал да и когда держал то не сильно. Но вот на примере Джави
Перегрузка методов с Т параметром в иерархии (неявное создание нового метода и неявний кол).
Да воодще при наследовании чертичто творится будет (тоесть творится то оно не будет, но ограничения будут).
Что там говорить, когда только пару недель назад в рассылки разработчиков Groovy, надо думать не самых убогих Java-разработчиков, недавно был коммент в духе - "эти чертовы генерики...понял кто-нибудь до конца, как они работают в Java !?!?"
Цитата: Zorkus
Что там говорить, когда только пару недель назад в рассылки разработчиков Groovy, надо думать не самых убогих Java-разработчиков, недавно был коммент в духе - "эти чертовы генерики...понял кто-нибудь до конца, как они работают в Java !?!?"
А с выводом типов все гораздо веселее получается, особенно когда имеется поддержка вариантности для интерфейсов и делегатов :) Nemerle, кстати, до сих пор имеет проблемы с обработкой некоторых случаев ограничений.
Есть сайт со сравнительно интересными статьями на тему Java:
http://www.skipy.ru/
Мне он интересен статьями об общей философии программирования и статьями об экспериментах (например, чем плохи мышекликальные техники создания GUI). Про статьи конкретно о Java мало что могу сказать. Возможно, есть смысл связаться с автором, если статьи покажутся разумными.
Другие идеи о будущем, о передачах на радио...
Возможно, надо следить за блогами авторов типа Кента Бека и Мартина Фаулера, т.е. за мыслителями, которые пропагандируют и Java. Первый - известный любитель SmallTalk, многое оттуда пытался перенести в Java, например, JUnit. Можно найти его рассуждения на счёт современных IDE для этого языка и проследить, что оттуда перенесено (будет перенесено) в IDE для Java. Второй пишет про Ruby (JRuby) и DSL. Где-то была его статья Groovy or JRuby (я её не осилил, но может пригодиться для передач).
http://www.skipy.ru/
Мне он интересен статьями об общей философии программирования и статьями об экспериментах (например, чем плохи мышекликальные техники создания GUI). Про статьи конкретно о Java мало что могу сказать. Возможно, есть смысл связаться с автором, если статьи покажутся разумными.
Другие идеи о будущем, о передачах на радио...
Возможно, надо следить за блогами авторов типа Кента Бека и Мартина Фаулера, т.е. за мыслителями, которые пропагандируют и Java. Первый - известный любитель SmallTalk, многое оттуда пытался перенести в Java, например, JUnit. Можно найти его рассуждения на счёт современных IDE для этого языка и проследить, что оттуда перенесено (будет перенесено) в IDE для Java. Второй пишет про Ruby (JRuby) и DSL. Где-то была его статья Groovy or JRuby (я её не осилил, но может пригодиться для передач).