Почему в Kotlin нет статического ключевого слова?

Kotlin известен прежде всего как замена Java, но он избавляется от известной конструкции Java: staticключевого слова. Вместо этого функциональность на уровне класса предлагается в основном сопутствующими объектами.

Что плохого в статических методах и полях, которым сопутствующие объекты предоставляют лучшую альтернативу? Я запутался в обосновании и не смог найти объяснения в документации.

Scala также заменяет объявления уровня класса объектом 'Singleton'. Основным преимуществом этого является то, что все является объектом. В Java статические члены обрабатываются совсем иначе, чем члены объекта. Это означает, что вы не можете делать такие вещи, как реализация интерфейса или помещение «экземпляра» вашего класса в карту или передача его в качестве параметра методу, который принимает Object. Сопутствующие объекты учитывают эти вещи. Это преимущество.

Ссылаясь на Kotlin справочные документы :

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

Мне кажется, очень похоже на то, что дизайнеры Kotlin видят в этом преимущество перед статическими членами Java.

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

Котлин - объектно-ориентированный язык. В объектно-ориентированном языке то, что не является объектом, является крайне вредным ограничением. Классы не являются объектами, но объекты являются объектами (дух!), Поэтому следует задать вопрос: почему язык не использует сопутствующие объекты?

Другим аспектом является простота: зачем иметь две вещи: объекты с членами экземпляра и классы со статическими членами, когда вы можете просто иметь объекты с членами экземпляра?

Альтернатива, которая используется во многих языках, производных от Smalltalk, состоит в том, чтобы самим создавать объекты. Например, в классах Smalltalk есть экземпляры параллельной иерархии метаклассов . В Ruby классы являются экземплярами Classкласса (и да, это означает, что Classэто экземпляр самого себя). В этом случае «методы класса» на самом деле являются обычными методами экземпляра метакласса класса. Я не знаю, почему этот дизайн не был выбран в Java (учитывая его близость к Smalltalk), но он может иметь какое-то отношение к упрощению системы типов (обратите внимание, что большинство языков с классами-как-объектами имеют тенденцию быть динамические языки).