История изменений

Вопросы были риторические - для примера, какой can of worms придется распечатать.

ни разу не распечатать — эти черви *уже* разбежались

в той же жабке одни чуваки, когда реализовывали кэш в оперативе, написали его на с/с++ (т.к. жц на ~16ГБ кошмарно тормозит) и дергали его через jni — на хабре была статья, причем они побенчили и получили, что у них быстрее, чем альтернативные реализации

это я к тому, что у чуваков объекты, собираемы gc, и не собираемые, сосуществуют вместе — и чуваки че-то не жалуются

Но если возьмешься отвечать - заодно скажи, что делать с виртуальным и обычным множественным наследованием.

на большую часть я отвечать не буду, отмазавшись тем, что топик про Д

насчет виртуального и обычным множественного наследования:

1. оно очень полезно и не требует особых сложностей, когда используется в стиле mix-in (т.е. когда не требуется кастить к *множеству* баз)

2. где-то может быть лучше «множественное» делегирование (страуструп в d&e писал, что вначале вместо наследования было делегирование, но там обнаружились некие проблемы — надо их изучить, тем более alias this это случайно не делегирование ли? примеров на dlang мало и один явно плохой, и я забил на выяснение этого)

3. но в любом случае бинарные данные вида «класс с++ с множественным наследованием» надо хотя бы потенциально уметь понимать — пусть даже использование такой плюсовой библиотеки приведет к тому, что где-то придется делать копирование вместо передачи по ссылке, или не делать сборку мусора, или х.з. что подобное

Но если не придется морочиться о совместимости с Си++, это само по себе большое облегчение.

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

Вопросы были риторические - для примера, какой can of worms придется распечатать.

ни разу не распечатать — эти черви *уже* разбежались

в той же жабке одни чуваки, когда реализовывали кэш в оперативе, написали его на с/с++ (т.к. жц на ~16ГБ кошмарно тормозит) и дергали его через jni — на хабре была статья, причем они побенчили и получили, что у них быстрее, чем альтернативные реализации

это я к тому, что у чуваков объекты, собираемы gc, и не собираемые, сосуществуют вместе — и чуваки че-то не жалуются

Но если возьмешься отвечать - заодно скажи, что делать с виртуальным и обычным множественным наследованием.

на большую часть я отвечать не буду, отмазавшись тем, что топик про Д

насчет виртуального и обычным множественного наследования:

1. оно очень полезно и не требует особых сложностей, когда используется в стиле mix-in (т.е. когда не требуется кастить к *множеству* баз)

2. где-то может быть лучше «множественное» делегирование (страуструп в d&e писал, что вначале вместо наследования было делегирование, но там обнаружились некие проблемы — надо их изучить, тем более alias this это случайно не делегирование ли? примеров на dlang мало и один явно плохой, и я забил на выяснение этого)

3. но в любом случае бинарные данные вида «класс с++ с множественным наследованием» надо хотя бы потенциально уметь понимать; пусть даже использование такой плюсовой библиотеки приведет к тому, что где-то придется делать копирование вместо передачи по ссылке, или не делать сборку мусора, или х.з. что подобное

Но если не придется морочиться о совместимости с Си++, это само по себе большое облегчение.

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