JEP 181: контроль доступа ко вложенным классам

На мой взгляд бесполезная фича, таким стараюсь не пользоваться. Инкапсуляция есть инкапсуляция.

При тормоза не понял. Там же простой геттер генерируется в 1 строчку, что мешает его заинлайнить во время JIT-компиляции?

ну это типа namespace в плюсах, да? делаешь класс-namespace, вложенные классы которого понижают уровень доступа к своим членам друг другу... не знаю, в плюсах было привычно. но в java - привык к другому подходу в связи с отсутствием предпосылок :)

Не нужно думать как организовать обмен данными у параллельных веток классов-потомков, пиши как попало, система утрётся!

ну типа, ты набыдлокодил так, что одна сущность развалилась на две, а склеить нельзя (потому что тебя все используют уже и им придется рефакториться)

да, тупанул, тормозов там быть не должно.

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

Статью по ссылке не читал.

Именно в таком виде, выглядит как-то нелогично и вообще нарушает принципы SOLID. Нахрена вообще модификаторы доступа придумывали тогда, если «соседний» класс может свободно ему приватные члены теребонькать ?

Хотя, если это как-то с точки зрения производительности что-то резко ускорит, и погромист сам как-то будет помечать такие классы специальным аттрибутом (или что там у джавистов, я хз), то может оно и полезная штука.

PS: смотря на последние новости по яве, я как-то всё больше рад что пишу на C#. В любом случае, я просто мимопроходил, не пинайте сильно.

Enchancement

Сомневаюсь

я как-то всё больше рад что пишу на C#

Ковариантность возвращаемых типов в С# уже завезли?

ну вот как раз производительность на втором месте. На первом люди, которые все пишут в одном файле во вложенных классах, и им сильно не хочется париться со сложностями доступа. Хочется посмотреть на этих людей)

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

Именно в таком виде, выглядит как-то нелогично и вообще нарушает принципы SOLID. Нахрена вообще модификаторы доступа придумывали тогда, если «соседний» класс может свободно ему приватные члены теребонькать ?

Именно в таком виде оно уже работает лет 20. Просто компилятор жавы генерирует скрытый метод и заменяет твоё обращение к приватному члену класса на вызов этого метода. JEP предлагает избавиться от этих искусственных методов и поддержать такое использование на уровне JVM. По сути язык Java и байткод JVM очень похожи, чаще всего конструкции Java компилируется один в один в очевидные конструкции байткода, но есть исключения, например эти самые синтетические методы. В языке Java есть понятие вложенных классов, а для JVM все классы одинаковые и вложенный класс ничем не лучше любого другого класса. Товарищи хотят JVM подогнать поближе под семантику Java.

Предположительно это поможет и Kotlin-у, там вроде private работает в пределах файла, а не класса.

Нет. Не завезли. Вы ведь это имеете ввиду: https://www.it-rem.ru/kovariantnost-vozvrashhaemyih-tipov-pri-pereopredelenii... , так ?

Вот, я подговтовил пример на C#, он не скомпилится именно по причине отсутствия данной фичи: http://rextester.com/NQHW85858

Вообще, да, мне этого раньше не хватало. Но за последние 3 года которые я программирую исключительно по SOLID'у и используя техники IOC и DI - я не сталкивался с данным неудобством. Так как практически везде оперирую интерфейсами или абстрактными классами. Так как по другому слабой связанности кода не достичь.

Конечно же, ООП надо закапывать.

используя техники IOC и DI

Использую техники макраме, могу реализовать абстрактную фабрику без IOC и DI... эм, этож одно и тоже? :)

Спасибо за ответ. Немного погуглил по этой теме, довольно интересно всё устроено.

Между тем, у меня это всё таки вызывает какой-то внутренний диссонанс. Не должна менять логика поведения модификаторов доступа в зависимости от вложенности класса. Это неправильно, ИМХО.

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

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

В C# этого нет, есть хренова туча разных фреймворков для этого, а я вот вообще вручную всё делаю (т.к легче и быстрее выходит).

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

Хочется посмотреть на этих людей

Я таких повидал достаточно в своей практике. Не только для C#. Хуже них только те кто везде суёт синглтоны.

в сам язык встроены инструменты для той-же инжекции зависимостей.

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

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

А то получается вы высказываете свое оценочное суждение, не основываясь ни на чем.

Я основываюсь на своём опыте разработки. Не на Java, да. Я вроде уже об этом написал. И я думаю, что я имею право высказать своё мнение основанное на своём опыте. Следуя вашей логике нельзя вообще ни о чём говорить пока вы не изучите вопрос досканально, что тоже неверно.

Раз вы такой гуру по яве и дотнету

Вот я не гуру по дотнету, совсем немного про него знаю, пришлось даже гуглить про дотнет.

почему доступ одних классов к приватным членам соседнего класса - считается нормальным.

Доступ к приватным челенам класса это вложенный в язык дизайн. Насколько я знаю, в C# никогда не было анонимных классов, т.е. в c# чтоб реализовать паттерн observer, до того как появилсь лямбды нужно было использовать делегаты. В java это делалось анонимными классами, которые исполняли роль лямбд до лямбд:

eventLoop.addListener(new Listener() {
    public void onEvent(Event evt) {
           // получаем доступ ко всем челнам обрамляющего класса, в том числе приватным
    }
})

Вот. Теперь ясно. Спасибо за развернутый ответ.

Да, без лямбд было туго в своё время. Анонимные типы в C# есть (https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-...). Но это совсем не то что имеется ввиду в данном случае.

А как же https://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков ?

Liskov's principle imposes some standard requirements on signatures that have been adopted in newer object-oriented programming languages:
...
Covariance of return types in the subtype.

Ну значит не свезло c# с solid.

Говорят, наследованием большинство пользуется неправильно.

Предполагается сделать эту фичу нативно, в байткодах JVM

А нафига вообще эти модификаторы доступа на уровне байткода? А потом при компиляции генерить лапшу типа kokoko$kudah$access$1
И все равно же можно через рефлекшон, залезть и даже поменять любое private поле.
Вот как нет дженериков в рантайме, так зачем там эти private, protected?

Как вам, нравится?

Да чо уж там, вносите friend.

А что я буду с этого иметь?

На мой взгляд бесполезная фича

Поалгаю имеется в виду ускорение работы анонимных классов.