Differences

This shows you the differences between two versions of the page.

--- ru:documentation:entrypoint [2022/03/26 22:07] – created furnygo
+++ ru:documentation:entrypoint [2022/03/27 22:36] (current) – external edit 127.0.0.1
@@ Line 41: / Line 41: @@
 ==== Типы ссылок на код ====
-Ссылка на код точки входа преобразуется в экземпляр типа прототипа точки входа. Наиболее распространенный способ создания точки входа - это ссылка на класс, который реализует ожидаемый тип, но эти ссылки на код могут быть сделаны несколькими способами. Внутренне языковой адаптер отвечает за интерпретацию ссылок и превращение их в экземпляры. Языковой адаптер по умолчанию предназначен для кода Java и, таким образом, поддерживает следующие типы ссылок:\\
+Ссылка на код точки входа преобразуется в экземпляр типа прототипа точки входа. Наиболее распространенный способ создания точки входа - это ссылка на класс, который реализует ожидаемый тип, но эти ссылки на код могут быть сделаны несколькими способами. Внутренне языковой адаптер отвечает за интерпретацию ссылок и превращение их в экземпляры. Языковой адаптер по умолчанию предназначен для кода Java и, таким образом, поддерживает следующие типы ссылок:
-**Будет переведено позже**
+  * **Ссылка на класс**: например, ''net.fabricmc.example.ExampleMod'' относится к неабстрактному классу с этим именем. Класс должен иметь открытый конструктор без аргументов. Класс должен реализовывать или расширять ожидаемый тип. Конечный объект является новым экземпляром класса.
------
+  * **Ссылка на метод**: например, ''net.fabricmc.example.ExampleMod::method'' сылается на открытый метод в этом классе с таким именем. Если метод нестатичен, для вызываемого метода создается новый экземпляр класса, что означает, что класс должен быть неабстрактным, а также иметь открытый конструктор без аргументов. Методы могут использоваться только для типов интерфейсов. Метод должен принимать те же аргументы и иметь тот же возвращаемый тип, что и абстрактные методы в интерфейсе. Конечное значение представляет собой прокси-реализацию интерфейса, которая будет реализовывать абстрактные методы путем делегирования этому методу.
-  * **Ссылка на класс**: ex. ''net.fabricmc.example.ExampleMod'' refers to the non-abstract class by this name. The class must have a public constructor with no arguments. The class must implement or extend the expected type. The resulting object is a new instance of the class.
+  * **Ссылка на статическое поле**: например, ''net.fabricmc.example.ExampleMod::field'' ссылается на поле в этом классе с таким именем. Поле должно быть статическим и общедоступным. Тип поля должен быть совместим с ожидаемым типом. Конечное значение - это значение этого поля.
-  * **Ссылка на метод**: ex. ''net.fabricmc.example.ExampleMod::method'' refers to a public method in that class by that name. If the method is nonstatic, a new instance of the class is constructed for the method to be called on, meaning the class must be non-abstract and also have a public constructor with no arguments. Methods can only be used for interface types. The method must accept the same arguments and have the same return type as the abstract method(s) in the interface. The resulting value is a proxy implementation of the interface, which will implement abstract methods by delegating to this method.
-  * **Ссылка на статическое поле**: ex. ''net.fabricmc.example.ExampleMod::field'' refers to the field in that class by that name. The field must be static and public. The the type of the field must be compatible with the expected type. The resuling value is the value of that field.
-References to class members must be unambiguous, meaning the class must contain one and only one field or method with the targeted name. The language adapter cannot resolve methods overloads. In case of ambiguity, the entrypoint will fail to resolve.
+Ссылки на члены класса должны быть однозначными, что означает, что класс должен содержать одно и только одно поле или метод с целевым именем. Языковой адаптер не может разрешить перегрузки методов. В случае двусмысленности точка входа не будет разрешена.
-Language adapters for other languages can be implemented by mods. [[https://github.com/FabricMC/fabric-language-kotlin|fabric-language-kotlin]] provides a language adapter for Kotlin.
+Языковые адаптеры для других языков могут быть реализованы модами. [[https://github.com/FabricMC/fabric-language-kotlin|fabric-language-kotlin]] предоставляет языковой адаптер для Kotlin.
 ==== Другие приложения точек входа ====
-Mods can call each others' entrypoints for integration purposes. An entrypoint is loaded lazily when entrypoints for a specific entrypoint prototype are requested, which makes an entrypoint an excellent tool for optional mod integrations. A mod may become an entrypoint prototype provider by declaring that other mods should provide entrypoints based on an entrypoint prototype, often using a class or interface that the mod provides in its API. Mods can safely use this class or interface even if the provider is not installed (rendering the class or interface inaccessible) because entrypoints are loaded only on request. When the provider is not present, the entrypoint will simply be ignored.
+Моды могут вызывать точки входа друг друга в целях интеграции. Точка входа загружается лениво, когда запрашиваются точки входа для определенного прототипа точки входа, что делает точку входа отличным инструментом для дополнительной интеграции модов. Мод может стать поставщиком прототипа точки входа, объявив, что другие моды должны предоставлять точки входа на основе прототипа точки входа, часто используя класс или интерфейс, который мод предоставляет в своем API. Моды могут безопасно использовать этот класс или интерфейс, даже если поставщик не установлен (что делает класс или интерфейс недоступными), поскольку точки входа загружаются только по запросу. Когда провайдер отсутствует, точка входа будет просто проигнорирована.
-Entrypoint instances can be accessed by calling ''FabricLoader#getEntrypointContainers(name, type)''. This returns a list of entrypoint containers. These containers contain the entrypoint instance and the mod container of the mod which provided the instance. This can be used by a mod to determine which mods have registered an entrypoint.
+Доступ к экземплярам точкам входа можно получить, вызвав ''FabricLoader#getEntrypointContainers(имя, тип)''. Это возвращает список контейнеров точки входа. Эти контейнеры содержат экземпляр точки хода и контейнер  мода, который предоставил экземпляр. Это может быть использовано модом для определения того, какие моды зарегистрировали точку входа.
-Entrypoint instances are memoized by their name and also their type. Using the same code reference for multiple entrypoints will result in multiple instances. Though highly absurd in practice, if ''getEntrypoints'' is called multiple times with the same name but different types, instances are constructed and memoized per type.
+Экземпляры точек входа запоминаются по их имени, а также по их типу. Использование одной и той же ссылки на код для нескольких точек входа приведет к созданию нескольких экземпляров. Хотя на практике это крайне абсурдно, если ''getEntrypoints'' вызывается несколько раз с одним и тем же именем, но разных типов, экземпляры создаются и запоминаются для каждого типа.
 ==== Примечание о порядке загрузки и фазах (или их отсутствии) ====
-Fabric Loader does not have a concept of a load order or loading phases. Initializer entrypoints are the mechanism with which most mod loading is usually done, but whether or not an initializer has been called does not determine whether or not a mod can be considered to be "loaded". Thus, it is unreasonable to expect that a mod has completed its modifications to the game after its initializers have been called. Additionally, the order in which entrypoints are called is mostly undefined and cannot be altered. The only guarantee is that a list of initializers in a fabric.mod.json file are called in the order in which they are declared. Fabric Loader does not provide multiple phases of initializers to work around the lack of order, either.
+Fabric Loader не имеет понятия о порядке загрузки или фазах загрузки. Точки входа инициализатора - это механизм, с помощью которого обычно выполняется большая часть загрузки модов, но независимо от того, был ли вызван инициализатор или нет, не определяет, можно ли считать мод "загруженным". Таким образом, неразумно ожидать, что мод завершил свои изменения в игре после того, как были вызваны его инициализаторы. Кроме того, порядок, в котором вызываются точки входа, в основном не определен и не может быть изменен. Единственной гарантией является то, что список инициализаторов в файле fabric.mod.json вызывается в том порядке, в котором они объявлены. Fabric Loader также не предоставляет несколько этапов инициализаторов для решения проблемы отсутствия порядка.
-A common example is the expectation that mod A should be able to load after mod B because mod A will replace an object registered by mod B. Alternatively, mod C wants to be loaded before mod D because mod D will do something in response to a registration performed by mod C. This is cannot be done for two reasons:
+Распространенным примером является ожидание того, что мод A должен иметь возможность загружаться после мода B, потому что мод A заменит объект, зарегистрированный модом B. В качестве альтернативы, мод C хочет быть загружен до мода D, потому что мод D сделает что-то в ответ на регистрацию, выполняемую модом C. Это невозможно сделать по двум причинам:
-  - Mod initializers are not required to represent a transition in a "mod loading lifecycle" so that after the initializer is called, all its registry objects are registered.
+  - Инициализаторы модов не требуются для представления перехода в "жизненном цикле загрузки модов", чтобы после вызова инициализатора регистрировались все его объекты реестра.
-  - The order in which mod initializers are called is undefined, and cannot be influenced so that mod A's initializers are called after mod B's initializers, or so that mod C's initializers are called before mod D's initializers.
+  - Порядок, в котором вызываются инициализаторы мод, не определен, и на него нельзя повлиять, чтобы инициализаторы мода A вызывались после инициализаторов мода B или чтобы инициализаторы мода C вызывались перед инициализаторами мода D.
-Leaving aside the missing guarantee of registration of all objects in initializers, one might argue that there should therefore be other entrypoints to perform "pre-initialization" and "post-initialization" so that there is a sense of order. This creates a multi-phase loading scheme, which in practice creates issues with the establishment of conventions for which operations are to be performed in which phase, uncertainty and lack of adherence to these conventions and outliers which do not fit.
+Оставляя в стороне отсутствующую гарантию регистрации всех объектов в инициализаторах, можно утверждать, что поэтому должны быть другие точки входа для выполнения "пре-инициализации" и "пост-инициализации", чтобы было ощущение порядка. Это создает многофазную схему загрузки, которая на практике создает проблемы с установлением соглашений, для которых операции должны выполняться на каком этапе, неопределенность и несоблюдение этих соглашений, а также выбросы, которые не соответствуют.