Вопрос

Есть ли какая-то рациональная причина, почему собственные свойства не будет частью Java 7?

Это было полезно?

Решение

Сделать свойства "правильными" в Java будет непросто.Работа Реми Форакса особенно ценна в выяснении того, как это может выглядеть, и выявлении множества "подводных камней", с которыми придется иметь дело.

Между тем, Java 7 уже заняла слишком много времени.Дебаты о закрытии были огромным, противоречивым отвлечением внимания, которое потратило впустую много сил разума, которые могли бы быть использованы для разработки функций (например, свойств), пользующихся широкой консенсусной поддержкой.В конце концов, было принято решение ограничить основные изменения модульностью (Project Jigsaw).Рассматривается только "небольшое изменение" для языка (в рамках Project Coin).

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

Другие советы

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

Но я думаю, что настоящая причина, по которой Sun не продвигает свойства, та же, что и closures:

1) Нет единого мнения о том, как должна выглядеть реализация.Или, скорее, существует множество конкурирующих альтернатив, и люди, увлеченные свойствами, расходятся во мнениях по поводу важнейших частей реализации.

2) Возможно, что еще более важно, существует значительное отсутствие консенсуса относительно того, нужна ли эта функция вообще.Хотя многим людям нужны свойства, есть также много людей, которые не считают это необходимым или полезным (в частности, я думаю, что люди на стороне сервера считают свойства гораздо менее важными для своей повседневной жизни, чем программисты swing).

История свойств здесь:

Любая данная вещь "не сделана" по умолчанию, поэтому не требуется никакой особой причины для того, чтобы что-то оставалось не сделанным.Скорее нужна какая-то веская причина, чтобы перевести что-то из категории "не сделано" в категорию "запланировано" или "сделано".Для этой языковой особенности пока не возникло достаточно веской причины.

Есть еще две причины избегать свойств на любом языке:

  • Свойства не очень объектно-ориентированы.Упрощение их написания поощряет шаблон, в котором объект просто передает свое внутреннее состояние, а вызывающий объект манипулирует им.Объект должен предоставлять методы более высокого уровня и сохранять свои внутренние компоненты закрытыми.В следующий раз, когда вы будете утомительно внедрять средство получения, подумайте, что вызывающий объект будет делать с данными и можете ли вы просто предоставить эту функциональность напрямую.

  • Свойства поддерживают изменяемое состояние (через установщики), что делает программу менее распараллеливаемой.По мере увеличения количества ядер мы все должны пытаться сделать наши объекты неизменяемыми, чтобы упростить параллельные рассуждения.В следующий раз, когда вы будете утомительно внедрять сеттер, подумайте о том, чтобы удалить его и сделать объект неизменяемым.

  • Не хватает времени?
  • Еще не определено должным образом?
  • Трудно добавить в java из-за реализации java?
  • Посчитали недостаточно важным, т.е. приоритет был отдан другим вещам?
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top