Будет ли синтаксис композиции полезным дополнением к Java?

Я не уверен, что вижу в этом явное преимущество. Я понимаю, о чем вы говорите. В настоящий момент для вызова метода на A у вас есть myB.getAInstance (). MethodInA (), но вы хотите сделать это myB.methodInA ().

Но что произойдет, если у вас будет несколько экземпляров A? Как будет разрешен вызов метода? Часто композиция подразумевает связь один-ко-многим, поэтому B имеет много экземпляров A. Что тогда происходит?

Я согласен с перечисленными вами недостатками. Это может просто вызвать слишком много путаницы, чем того стоит.

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

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

Также следует учитывать разницу между состав и агрегирование. Как компилятор узнает, имеете ли вы в виду отношения «есть» или «имеет»?

• Подходит ли для сборки мусора весь граф объектов или только его заголовок?

Пара инструментов сопоставления ORM и фреймворков над ними или вокруг них обеспечивают отношения belongsTo или has-many между постоянными объектами, а некоторые также обеспечивают каскадное удаление (для композиции). Я не знаю ни одного свободного предложения, которое предоставляет простой синтаксический сахар, который вы ищете.

На самом деле, если задуматься, идиомы Groovy MetaClass и MetaProgramming могут предоставить нечто очень похожее с «автоматическим магическим» делегированием.

Множественное наследование разрешено в C++, я знаю, что по-разному, но это один и тот же мыслительный процесс. Java была разработана так, чтобы не допускать множественного наследования, чтобы было меньше путаницы, а следовательно, ошибок и эксплойтов.

То, что вы предложили, прямо противоречит принципам java.

Сказав это, это было бы круто (не обязательно полезно). Я программист на Java, перешедший с C++. Мне нравится делать собственные ошибки.

Ознакомьтесь с тем, что называется «миксинами» на некоторых языках и «ролями» в системе Perl 5 Moose OO.

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

Лично я ненавижу наследование конкретных классов. Я большой сторонник пункта 14 из статьи Блоха Эффективная Java, Предпочитайте композицию наследованию. Я думаю, что что-то подобное упростит реализацию идиомы, которую он рекомендует в этом пункте.

Честно говоря, если бы вы действительно знали, что делаете, держу пари, вы могли бы написать аннотацию компилятора, которая справилась бы с этим. Итак, если у вас есть класс Bar, в котором реализован интерфейс IBar, ваш класс будет выглядеть так:

public class Foo {

  @Delegate(IBar.class)
  private Bar bar;

  // initialize bar via constructor or setter
}

Затем во время компиляции Foo можно было бы заставить реализовать IBar, и любой из методов в этом интерфейсе, которые еще не были реализованы Foo, в конечном итоге будет сгенерирован следующим образом:

public Baz method1(Qux val) {
  return bar.method1(val);
}

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

Теперь, когда я это написал, это кажется довольно крутым. Может быть, я поиграюсь с ним на следующей неделе. Я обновлю это, если мне удастся что-нибудь выяснить.