Почему в Java 7 не будет нативных свойств?
Есть ли рациональная причина, почему нативные свойства не будут частью Java 7?
5 ответов
Делать свойства "правильно" в Java будет нелегко. Работа Реми Форакса была особенно полезна для выяснения того, как это может выглядеть, и для раскрытия многих "ошибок", с которыми придется иметь дело.
Между тем Java 7 уже заняла слишком много времени. Дебаты о замыканиях были огромным спорным отвлечением, которое потратило много сил и разума, которые могли бы быть использованы для разработки функций (таких как свойства), которые имеют широкий консенсус поддержки. В итоге было принято решение ограничить серьезные изменения в модульности (Project Jigsaw). Для языка рассматривается только "небольшое изменение" (в разделе "Монета проекта").
JavaFX имеет прекрасную поддержку свойств, поэтому Sun четко понимает ценность свойств и знает, как их реализовать. Но будучи испорченными свойствами JavaFX, разработчики с меньшей вероятностью согласятся на полусгнившую реализацию в Java. Если они того стоят, они того стоит.
Есть несколько причин высокого уровня, связанных с графиком и ресурсами, конечно. Реализация свойств и понимание всех последствий и пересечений с другими языковыми функциями - большая задача, подобная размеру различных изменений языка Java 5.
Но я думаю, что настоящая причина, по которой Sun не продвигает свойства, такая же, как у замыканий:
1) Нет единого мнения о том, как должна выглядеть реализация. Или, скорее, есть много конкурирующих альтернатив, и люди, которые увлечены свойствами, не согласны с важными частями реализации.
2) Возможно, что еще более важно, существует значительное отсутствие консенсуса относительно того, нужна ли функция вообще. В то время как многие люди хотят свойства, многие также не считают его необходимым или полезным (в частности, я думаю, что серверные люди считают свойства гораздо менее важными для их повседневной жизни, чем программисты на колебаниях).
История свойств здесь:
По умолчанию любая заданная вещь "не выполнена", поэтому для того, чтобы что-то не было сделано, не требуется особой причины. Скорее, необходима некая убедительная причина, чтобы перевести что-то из "не выполненного" в "запланированное" или "выполненное" Для этой языковой функции пока не возникло достаточно веских причин.
Есть еще две причины избегать свойств на любом языке:
Свойства не очень объектно-ориентированы. Упрощение их написания поощряет шаблон, в котором объект просто обслуживает свое внутреннее состояние, а вызывающий объект манипулирует им. Объект должен предоставлять методы более высокого уровня и сохранять его внутренние данные закрытыми. В следующий раз, когда вы утомительно внедряете метод получения, подумайте, что будет делать вызывающий с данными, и можете ли вы просто предоставить эту функцию напрямую.
Свойства поддерживают изменяемое состояние (через установщики), что делает программу менее распараллеливаемой. По мере того как количество ядер увеличивается, мы все должны пытаться сделать наши объекты неизменяемыми, чтобы облегчить одновременное рассуждение. В следующий раз, когда вы утомительно реализуете сеттер, подумайте о том, чтобы удалить его и сделать объект неизменным.
- Недостаточно времени?
- Еще не определен правильно?
- Сложно добавить в Java из-за реализации Java?
- Считается недостаточно важным, то есть другие вещи были в приоритете?