Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Самый важный вопрос. В текущем виде дженерики — фича времени компиляции, и никаких типов-значений они поддерживать не будут. Но раз уж сказал «А» (типы-значения), то говори и «Б», поэтому рано или поздно дженерики переделают.Это ваши личные догадки? И прогнозы в том числе?
Из оригинала:
Будет очень странно добавить типы-значения и потом жить с этим «dramatically increased irritation».
Вообще специализация примитивов просится давно и ИМХО даже важнее типов-значений.
It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”.Будет очень странно добавить типы-значения и потом жить с этим «dramatically increased irritation».
Вообще специализация примитивов просится давно и ИМХО даже важнее типов-значений.
Когда типы-значения появятся, JRE уйдет с еще большего количества компьютеров.
Опущены детали предложения по реализации типов-значений на уровне байт-кода, что не очень интересно для большинства Java-программистов.
Как раз таки самое интересное :)
Ну новые байт-коды. Или не новые. Тем кто не пишет свой язык на основе JVM или не поддерживает свою библиотеку для генерации кода вообще без разницы.
Как я понял, это Case Classes?
Case-классы отличаются от обычных только наличием генерируемых компилятором методов доступа к полям и объекта компаньона. А в памяти размещаются также как и обычные классы. Здесь же речь про возможность размещения данных на стеке, а не в куче. Помниться в скала-группе обсуждали возможность введения типов-значений и там высказывалось мнение, что они никогда не появяться в jre.
Не похоже.
Нет, это Value Classes
Да. Но mutlifield. И механизм добавления методов другой(у Scala — тут работает стандартный механизм implicit декораторов).
Однако Dotty с интересом наблюдает за тем, что будет в JVM.
Заодно это касается Universal Traits в Scala docs.scala-lang.org/overviews/core/value-classes.html
Однако Dotty с интересом наблюдает за тем, что будет в JVM.
Заодно это касается Universal Traits в Scala docs.scala-lang.org/overviews/core/value-classes.html
Сумбурно написано о ссылочном типе-обертке. Нужно, чтобы ссылочный тип можно было въявную указывать при определении переменной: как int и Integer.
— Типы-значения могут содержать и обычные объектные поля (которые не обязаны быть рекурсивно неизменяемыми, как сами значения), и поля других типов-значений. Но: не могут содержать поля своего же типа.
Спорно, т.к. стороны это нарушает труЪ-immutability.
Поля должны давать возможность быть ссылочной оберткой типа для реализации рекурсивных структур типа бинарного дерева:
_ByValue class Node {
Node? left, right; // Синтакс C#
}
— Тип-значение не может наследовать ни классу, ни другому типу-значению, от типа-значения ничего нельзя наследовать.
Спорно. Vector3D extends Vector2D… При присваивании просходит преобразование значения:
Vector3D v3 = ...;
Vector2D v2 = v3; // OK
Vector3D v3_1 = (Vector3D) v2; // Error
— Применение рефлексии к значению.
:( А в чем проблема? Это затруднит интроспекцию структуры, и динамическое получение данных. Половина фреймворков отвалится. Представьте, что в Hibernate нужно замепить value-type как Entity или @Embeddable…
— Присвоение переменной типа-значения null.
Если у меня поле имеет value-type, я должен указывать въявную дефолтное значение? Или default value определено как default value всех его простых полей?
public Vector3D v; // дефолтное значение Vector3D(0,0,0);
— Приведение к Object или любому супертипу.
Autoboxing к ссылочной обертке???
Почему не взлетит?
— очень толстое изменение, затрагивающее работу JVM практически на всех уровнях.
— текущие API Java не заточены под использование value-types. Потребуется либо полная переработка API, либо создание нового API (RTL 2.0).
— также многие библиотеки и фреймворки не заточены под использование value-types. Это новый концепт, который может польностью нарушить работу существующего функционала.
— все уже есть в scala
— Типы-значения могут содержать и обычные объектные поля (которые не обязаны быть рекурсивно неизменяемыми, как сами значения), и поля других типов-значений. Но: не могут содержать поля своего же типа.
Спорно, т.к. стороны это нарушает труЪ-immutability.
Поля должны давать возможность быть ссылочной оберткой типа для реализации рекурсивных структур типа бинарного дерева:
_ByValue class Node {
Node? left, right; // Синтакс C#
}
— Тип-значение не может наследовать ни классу, ни другому типу-значению, от типа-значения ничего нельзя наследовать.
Спорно. Vector3D extends Vector2D… При присваивании просходит преобразование значения:
Vector3D v3 = ...;
Vector2D v2 = v3; // OK
Vector3D v3_1 = (Vector3D) v2; // Error
— Применение рефлексии к значению.
:( А в чем проблема? Это затруднит интроспекцию структуры, и динамическое получение данных. Половина фреймворков отвалится. Представьте, что в Hibernate нужно замепить value-type как Entity или @Embeddable…
— Присвоение переменной типа-значения null.
Если у меня поле имеет value-type, я должен указывать въявную дефолтное значение? Или default value определено как default value всех его простых полей?
public Vector3D v; // дефолтное значение Vector3D(0,0,0);
— Приведение к Object или любому супертипу.
Autoboxing к ссылочной обертке???
Почему не взлетит?
— очень толстое изменение, затрагивающее работу JVM практически на всех уровнях.
— текущие API Java не заточены под использование value-types. Потребуется либо полная переработка API, либо создание нового API (RTL 2.0).
— также многие библиотеки и фреймворки не заточены под использование value-types. Это новый концепт, который может польностью нарушить работу существующего функционала.
— все уже есть в scala
1) Пожалуй да, но в Java пока нет понятия const ref и мне не очень понятно, как его делать или проверять.
2) Как раз логично. Иначе структура будет «бесконечной». Хоть в голом Си все равно придется ссылки делать. В лучшем случае Это будет
3) Почитайте оригинал, там это обсуждается. Значение не таскает с собой ссылку на свой тип, поэтому на нем нельзя сделать полиморфный вызов.
4) То же, что и выше. Значит нельзя замапить. Либо ОРМы будут требовать самописные мапперы для типов-значений. Либо интроспектировать одно значение один раз, сгенерировать маппер и ходить им по необернутым значениям.
5) Второе, более того, дефолтный конструктор в типах-значениях будет запрещен по избежание разночтений. А методы должны учитывать что помимо инвариантов в полях могут быть просто нули в любом случае. Но присваивать
6) Да
— Дженерики еще толще. Но надо, надо
— Текущие API живут как и жили. А кто пишет числодробилки, или какой-то код который генерирует миллионы мелких объектов и не может от этого избавиться, будет рад.
— В Java никогда не добавят то, что может «полностью нарушить работу существующего функционала».
— Судя по комментариям выше, нет. И я думаю почти невозможно прикрутить к JVM-языку нормальные типы-значения сбоку в обход JVM. Как, допустим, вернуть значение-кортеж из метода?
2) Как раз логично. Иначе структура будет «бесконечной». Хоть в голом Си все равно придется ссылки делать. В лучшем случае Это будет
class __ByValue class Node {
Node.__Boxed left, right;
}
3) Почитайте оригинал, там это обсуждается. Значение не таскает с собой ссылку на свой тип, поэтому на нем нельзя сделать полиморфный вызов.
4) То же, что и выше. Значит нельзя замапить. Либо ОРМы будут требовать самописные мапперы для типов-значений. Либо интроспектировать одно значение один раз, сгенерировать маппер и ходить им по необернутым значениям.
5) Второе, более того, дефолтный конструктор в типах-значениях будет запрещен по избежание разночтений. А методы должны учитывать что помимо инвариантов в полях могут быть просто нули в любом случае. Но присваивать
null будет либо нельзя совсем, либо только для совместимости с существующим кодом типа point = null;.6) Да
— Дженерики еще толще. Но надо, надо
— Текущие API живут как и жили. А кто пишет числодробилки, или какой-то код который генерирует миллионы мелких объектов и не может от этого избавиться, будет рад.
— В Java никогда не добавят то, что может «полностью нарушить работу существующего функционала».
— Судя по комментариям выше, нет. И я думаю почти невозможно прикрутить к JVM-языку нормальные типы-значения сбоку в обход JVM. Как, допустим, вернуть значение-кортеж из метода?
удалено
Автор, может лучше называть их «значимые типы», как в MSDN? А то типы-значения как-то непонятно.
Скажите, а можно ли начать использовать родные многим типы вроде uint32_t, uint16_t и т.д. Я понимаю, что это конечно отдает чистым C/C++. Хотя конечно они только внесут еще больше хаоса в разработку, но часть алгоритмов сжатия и сдвигов можно будет на них выполнять.
Можно, используйте. Примитивы int, long, short — это они и есть.
Для беззнакового сдвига есть специальные операторы, если нужно.
Для беззнакового сдвига есть специальные операторы, если нужно.
Микс знаковых и беззнаковых типов рождает хаос везде и всюду :-)
Не надо так делать в Java. Иначе на каждой арифметической операции придется думать об ошибках переполнения.
Не надо так делать в Java. Иначе на каждой арифметической операции придется думать об ошибках переполнения.
(1) Я слышал, что Oracle одной из целей на java 9 ставит переработку взаимодействия с нативным кодом (JNI). (2) Если я правильно понял, то ближайший аналог «типов значений» в Си — это структуры.
(1) без (2) получится плохо, а значит у нас есть хороший шанс увидеть «типы значения» уже в java 9.
(1) без (2) получится плохо, а значит у нас есть хороший шанс увидеть «типы значения» уже в java 9.
Язык для этого не приспособлен. Если в Java добавят типы-значения, то это будет уже не Java, а какое-то уродство, тем более без перегрузки операторов. ИМХО
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типы-значения в Java