Почему названия классов, методов меняется к версии?

14
1
Доброго всем :)

Такой вопрос меня замучал. Почему от версии к версии очень часто вижу что названия классов или методов (не все, естественно) меняются? :unsure:
Чем это обусловлено? Почему если взять код (который делает одно и тоже в любой версии) из версии 1.16.5 или 1.18.2 он не будет работать в 1.9 и выше?
 
1,371
112
241
Чем это обусловлено?
Mojang.
Почему если взять код (который делает одно и тоже в любой версии) из версии 1.16.5 или 1.18.2 он не будет работать в 1.9 и выше?
Потому что с 1.13 игру, считай, переписали. И код сильно разнится. Это 1. А 2 - разные маппинги (названия методов и полей).
 
1,371
112
241
А зачем? Зачем нужен этот интерфейс?
игру, считай, переписали.
Если и будет создаваться какой-либо интерфейс для этого, то утверждать, что он будет хотя бы на 50% рабочим - ошибочно.
Заменялись библиотеки, местами менялся код игры с ног на голову. Подход к созданию модов тоже сильно изменился. В частности, сервер-клиент разделение, которые в игре играет огромнейшую роль, тоже изменилось. Точнее, реализация этого дела.
Что уж говорить о зоопарке модлоадеров - Quilt, Forge, Fabric, LiteLoader и пр.
Тем более, что большая часть хоть сколь-нибудь крупных модов уже пересела на 1.16 и выше. Этот интерфейс (если бы он был реален) был бы полезен раньше, но не сейчас.
Прежде чем заявлять о подобных богоподобных инструментах, стоило бы разобраться в вопросе разницы версий. Говорю как человек, писавший и на 1.7, и на 1.12, и на 1.16, и на 1.20.
 
14
1
был бы полезен раньше, но не сейчас
Возможно. Но для новичков было бы удобнее такое решение. К несчастью приходится плавать так.
В принципе, порог вхождения выше, недомодов меньше. :unsure:
 
1,371
112
241
Ничего внеземного.
Друг, разберись в теме сначала.

Как быть с переработанной системой пакетов? Что делать с IEEP и Capability? Как там по рендеру? Что делать с ушедшими прокси? Как существовать с обновившимся функционалом (со стороны разработчика) доброй половины игры?
Ну и про зоопарк модлоадеров тоже не забываем.

Если какой-то человек сможет создать инструмент, который будет адекватно переводить хотя бы 80% мода - это уже что-то очень невероятное. (Я не беру в учёт моды, которые, условно, просто добавляют аналог железки и алмазки)
 
14
1
Друг, разберись в теме сначала.

Как быть с переработанной системой пакетов? Что делать с IEEP и Capability? Как там по рендеру? Что делать с ушедшими прокси? Как существовать с обновившимся функционалом (со стороны разработчика) доброй половины игры?
Ну и про зоопарк модлоадеров тоже не забываем.
Вопрос здесь о использование классов и методов. Если допустим, мы получаем инвентарь в одной версии одним путем, в другой версии, переименовали, выкинули, изменили - не имеет разницы, мы обращаемся к интерфейсу, в котором уже реализована верная, к текущей версии игры, версия получения инвентаря. Если два класса были в новой версии совмещены, мы удаляем не требующий интерфейс, используем один.

Здесь вопрос в самом программирование.
 
1,371
112
241
Вопрос здесь о использование классов и методов. Если допустим, мы получаем инвентарь в одной версии одним путем, в другой версии, переименовали, выкинули, изменили - не имеет разницы, мы обращаемся к интерфейсу, в котором уже реализована верная, к текущей версии игры, версия получения инвентаря. Если два класс были в новой версии совмещены, мы удаляем не требующий интерфейс, используем один.
Я уже сказал выше:
Подход к созданию модов тоже сильно изменился. В частности, сервер-клиент разделение, которые в игре играет огромнейшую роль, тоже изменилось. Точнее, реализация этого дела.
Как быть с переработанной системой пакетов? Что делать с IEEP и Capability? Как там по рендеру? Что делать с ушедшими прокси? Как существовать с обновившимся функционалом (со стороны разработчика) доброй половины игры?

Представим мысленный эксперимент. В условиях оного мы только-только переходим с 1.12.2 на 1.13, а предложенный тобою инструмент существует. (хотя в реальности уже сразу переходили на 1.14, но опустим это).
Тогда, подставив некий "шаблон" вместо получения пакета, мы получим:
а) Тонну ошибок о несуществующем пакете
б) Возможно неверную интерпретацию изначального кода
в) Повсеместно поломанный рендер (если это сервер-клиент пакет)
г) Отсутствие или иная работа эвентов (при отправке пакета)
И, наконец, д) Нерабочий мод

Я уже сказал ранее: игра до 1.13 и после - это, с точки зрения кода, а значит и разработчика мода, чуть ли не 2 разные игры.
Повторю вновь: РАЗБЕРИСЬ В ЗАДАННОМ ТОБОЮ ВОПРОСЕ. Я отвечаю тебе исходя из того, что ты уже умеешь создавать какие-либо моды на 1.12 и 1.13+.
Если тебе интересно: Forge для 1.13 был также переписан, а я напомню тебе, что разрабы Forge весьма скверны характером, когда дело касается каких-либо нововведений в их API.

Иначе говоря, то, что ты предлагаешь, будет работать лишь на 20-30%, не более. Здесь нужен гораздо более комплексный инструмент.
Более того, сейчас подобный инструмент никому не нужен.
 
14
1
Ты наверное не до конца меня понял.

Вот пример:

Java:
class BirthdayClass {
    public String getCake(String name) {
        return "Поздравляю с днем рождения! Вот твой торт " + name + "!";
    }
}

class InterfaceBirthdayClass {
    private final BirthdayClass original;

    public InterfaceBirthdayClass() {
        this.original = new BirthdayClass();
    }

    public String getCake(String name) {
        return original.getCake(name);
    }
}

class Main {
    public static void main(String[] args) {
        String name = "Tom";
        InterfaceBirthdayClass birthday = new InterfaceBirthdayClass();
        System.out.println(birthday.getCake(name));
    }
}

А теперь мы выпустим новую версию нашего функционала "Дня рождения":

Java:
class BirthdayClass {
    public String congratulation() {
        return "Поздравляю с днем рождения!";
    }

    public String cake(String name, String speech) {
        return speech + " Вот твой торт " + name + "!";
    }
}

class InterfaceBirthdayClass {
    private final BirthdayClass original;

    public InterfaceBirthdayClass() {
        this.original = new BirthdayClass();
    }

    public String getCake(String name) {
        String speech = original.congratulation();
        return original.cake(name, speech);
    }
}

class Main {
    public static void main(String[] args) {
        String name = "Tom";
        InterfaceBirthdayClass birthday = new InterfaceBirthdayClass();
        System.out.println(birthday.getCake(name));
    }
}

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

Вопрос именно в этом мой и состоял, почему разработчики страдают. Разве это не проще?
 
1,371
112
241
Вопрос именно в этом мой и состоял, почему разработчики страдают. Разве это не проще?
Твой пример слишком простой. Если мы будем рассматривать его - да, так действительно проще.
Но теперь посмотри на реализацию отправки и приёма пакета на 1.12 и 1.13. Разница слишком большая.

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

Повторяю в который раз: версии 1.12 и 1.13 сильно отличаются. Такой инструмент, который ты предлагаешь, очень трудно реализуем.

Если же ты говоришь исключительно о названиях методов/классов - никто тебе не мешает использовать старые маппинги. Ты можешь их подключить в gradle. НО! Названия методов и классов могут не совпадать с их реализацией, хотя их имена останутся теми же.
 
14
1
Ты как-то зациклился 1.13 ?)))) Я понял тебя что игра была переписана) Это очень печально, но факт. Я больше топлю в ту сторону, что это может повториться. А также многие гайды от версии к версии тупо неактуальны. Начал я разработку на 1.19, не нашел гайдов к своему вопросу, есть он в 1.16.5 - но что использовали в гайде - не актуально в нынешней версии. Проблема осталась, не смотря на 1.13
 
14
1
Я разработчик на питоне, в нашем мире это все просто. Я не отрицаю, что не понимаю многие вещи джавы и возможно абстрагирование в ней это сложная штука которая еще не актуальна.
 
1,371
112
241
Начал я разработку на 1.19, не нашел гайдов к своему вопросу, есть он в 1.16.5 - но что использовали в гайде - не актуально в нынешней версии.
На 1.17 был осуществлён переход к новой версии Java. Также была начата перепись генератора мира. Местами изменили рендер. Также осуществлён рефакторинг кода.
И да, если ты хочешь получить инфу на версии поновее, ищи на англ. Там туториолав для вкатывания в моддинг полно (Kaupenjoe, например).
Ты как-то зациклился 1.13
Наиболее яркий пример.
Можно вспомнить 1.7 и 1.8, 1.5 и 1.6, 1.8 и 1.9, 1.16 и 1.17 - они все из этой же серии.
Даже 1.16.3 и 1.16.4, хоть и минимально, но отличаются. 1.19.3 и 1.19.4 требуют замены большинтсва импортов. Местами требуется другая реализация (креативные вкладки, например).
Я разработчик на питоне, в нашем мире это все просто.
Minecraft, сам по себе, с закрытым исходным кодом. Так что Mojang что хотят, то и воротят. А уж как там мододелам будет - им всё равно. Лишь недвано появились хоть какие-то подвижки в эту сторону.
Forge, Fabric и пр. - надстройка над майном, потому они вынуждены отталкиваться от оригинала. А если сам оригинал от версии к версии меняется, то как и им не меняться?
Я не отрицаю, что не понимаю многие вещи джавы и возможно абстрагирование в ней это сложная штука которая еще не актуальна
Ты просто не работал с таким подходом к разработке, когда половин вещей может измениться в сию же секунду. А готовых либ тебе никто не даст. Вот и крутись как хочешь.
 
14
1
Что ж, выводы сделаны, стало все на своим места. Благодарю за объяснение.
 
Сверху