Minimal Value Types

хочется услышать ваше авторитетное мнение по поводу «нужно» либо «не нужно».

если это не будет порождать костыли типа автобоксинга - то нужно

Безусловно нужно. На какой-нибудь UUID или LocalDateTime жалко тратить столько накладных расходов. Мелкие строки бы тоже было круто засовывать в такие типы. 128 битов это 16 ASCII-символов или 8 типичных юникодных символов, это наверное 90% значений в типичной программе.

ты про язык Java?

на этапе минимального прототипа, в самом языке Java нет вообще нет поддержки прямого управления Q-типами. Просто нет таких ключевых слов и аттрибутов

вся тема происходит в байткоде, и там да - везде используется хитрый автоматический автобоксинг. С другой стороны, поскольку для таких объектов нет никакого смысла в обычной ссылочной эквивалентности или эскейп-анализе, по ресурсам такой боксинг не стоит почти ничего (на стандартном ворклоаде, массив Q-типов из элементов «инты парами» работает примерно как обычный массив, в котором примитивных интов в два раза больше, и иногда даже чуть быстрее, т.к. JVM немного знает структуру и может иногда применять оптимизации пачек и автовекторизацию)

на этапе расширенного прототипа (который, кажется, уже существует, но не дошли руки), будет поддержка и в языке. Естественно, при работе с Q-типами в жабе, «ощущаться» они будут как обычные объекты, и это может привести к какоаму-то изначальному боксингу. Но в конце концов, он тоже будет почти бесплатный.

Лол. Какую фичу следующей потащат из Scala?

А массива байтов нет?

а при чем тут Scala? Scala работает на JVM, текущая JVM не умеет в value types. Без изменений в JVM любая запись этой сущности в синтаксисе любого jvm-языка будет всего лишь синтаксическим сахаром над лютейшим боксингом, отчего перфоманс будет прямо скажем, не bare metal. Чтобы это заработало, в JVM будут добавлены новые байткоды для value-type операций, вначале некая основная часть «чтобы просто заработало» (как и описано в этом тексте), потом появятся апи для удобной работы и станут доступны через invokedynamic, потом некоторые часто используемые фичи станут байткодами

Конечно нужно.

Особенно если сделают.

Какую фичу следующей потащат из Scala?

за шо я обожаю скала-фанбоев так это за то что они обмазались всяким сахаром, а как там усе устроено под капотом не знают, потому и их чудо-код работает хуже чем хипсторский жабаскрипт

https://docs.scala-lang.org/overviews/core/value-classes.html

Читай, дурилка, как оно работает.

В Скале там была фича с Generics над примитивными типами в T, что оно вроде умело генерировать специализацию, а не реальный Generic (в котором по сути Object).

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

дурилка

Интеллектуала выдает культура прущая из него как нарзан из канализации.

Уж кто бы говорил.

В Скале там была фича с Generics над примитивными типами в T, что оно вроде умело генерировать специализацию, а не реальный Generic (в котором по сути Object).

В данном случае я о другой фиче: https://docs.scala-lang.org/overviews/core/value-classes.html

Да, там именно это и написано:

Because the JVM does not support value classes, Scala sometimes needs to actually instantiate a value class. Full details may be found in SIP-15.

This is accomplished through the definition of new AnyVal subclasses.Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation.

Нормальные типы-значения в JVM будут делать всё это во много раз лучше, уже просто со старта. И органичения на их использование будут куда как мягче (т.е. они реально будут всегда работать, а не «ой, сломалось»). И Scala сможет мгновенно этим воспользоваться под капотом.

Ограничения и взялись из-за того, что разработчики Scala не могут по своей воле менять спецификации JVM.

То что переносят фичи из Скала - это очень хорошо.

То что переносят фичи из Скала - это очень хорошо.

Разумеется. Я просто хотел тролльнуть в соответствии с традициями всеобщего ненужно, принятыми на ЛОРе.

чуваки, или вы сошли с ума, или я - наркоман

никто не «переносит фичи из Scala».

JVM нельзя сравнивать со Scala, это разные вещи. Scala можно сравнивать с языком Java.

так вот в Java value types еще НЕ появились, а может быть и вообще не появятся (будут существовать как скрытая оптимизация)

JVM можно сравнивать с другими виртуальными машинами и рантаймами. Например, насколько знаю, в .NET CLR value types существуют.

но это даже нельзя назвать «переносом фич из .NET», потому что value types это базовая теоретическая идея, она появилась задолго до появления JVM и .NET как таковых, появилась вместе с первыми попытками сделать виртуальную машину для объектно-ориентированного языка.

чуваки, или вы сошли с ума, или я - наркоман

ты конечно тот еще наркоман, но это скала-фанбои

в Java value types еще НЕ появились, а может быть и вообще не появятся

тогда ненужно.

но это даже нельзя назвать «переносом фич из .NET», потому что value types это базовая теоретическая идея, она появилась задолго до появления JVM и .NET

Назовите в каких ещё рантаймах с JIT и байткодом это было?

value types это базовая теоретическая идея

В базовой теоретической идее противопоставление value type и reference type идёт только в контексте глубокого копирования, не затрагивая вопросы представления, размещения на стеке/в куче и боксинга. Иными словами, поддержка value types — это свойство именно языка. Свойство рантайма — это оптимизация представления значений value type.

В scala, классы, которые extends AnyVal, являются синтаксическим костылём, который разруливается в scalac.

Отчасти поэтому, AnyVal-классы могут иметь ровно один аргумент в «конструкторе». Т.е. нельзя в scala реализовать пример по ссылке, где передаются два double-аргумента в value-type конструкторе.

И нельзя будет до тех пор, пока в jvm эта поддержка не появится.

По SIP-15 VT должен быть эфемерным:

A class or trait C is ephemeral if the following holds:

- C may not declare fields (other than the parameter of a value class).
- C may not contain object definitions.
- C may not have initialization statements.

Т.е. не только в конструкторе нельзя передать больше 1 значения, но и вообще никаких полей иметь нельзя

По сути юзать их можно только для овеществления всяких метрик типа скорости

Все сложные вопросы, о которых там рассуждают Роуз и Гёц оставлены на попечение пользователю - т.е. скорей всего, не будут решаться никак

Scala AnyVal-классы внутри — это по сути автоматическая конвертация n-arity методов класса в статические (n+1)-arity методы, сваленные в отдельном сгенеренном классе, где нулевой аргумент метода — это единственный аргумент воображаемого AnyVal-конструктора.

В scala часто такая трансформация используется: например, до java8+scala2.12, дефолтовые реализации методов в trait'ах (интерфейсах) просто сбрасывались в отдельный искусственный класс и становились статическими по той же схеме.

Так аналог шарповых структур давно же запилить хотят, несколько лет уже. А это как раз оно и есть, как я понимаю.

Медленно разгоняются. Позовите, когда «изобретут» беззнаковые типы и адресную арифметику.

Интеллектуала выдает культура прущая из него как нарзан из канализации.

за шо я обожаю скала-фанбоев так это за то что они обмазались всяким сахаром, а как там усе устроено под капотом не знают, потому и их чудо-код работает хуже чем хипсторский жабаскрипт

Ну да.

Вот когда запилят, тогда и приходи со своей простыней. Я эту хрень ещё с 14-го года жду, когда шла речь о вычислениях на ГПУ нативно из ЖВМ.

И что я слышу в итоге, когда одному из ведущих разрабов задают вопрос: «Кто сейчас работает над проектом Саматра?» - Никто.

По ссылке не ходил, но судя из описания первая действительно нужная вещь со времен шестой жабы.

зачем вообще нужны беззнаковые типы и адресная арифметика _в_жабе_?

sun.misc.Unsafe