Scarfski/entt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: review locator.md

Browse Source
This commit is contained in:
Michele Caini
2022-10-25 11:04:13 +02:00
parent 4a98874431
commit 6a53c8eaca
1 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/md/locator.md
View File

@@ -14,9 +14,9 @@
# Introduction
Usually service locators are tightly bound to the services they expose and it's
Usually, service locators are tightly bound to the services they expose and it's
hard to define a general purpose solution.<br/>
This tiny class tries to fill the gap and to get rid of the burden of defining a
This tiny class tries to fill the gap and gets rid of the burden of defining a
different specific locator for each application.
# Service locator
@@ -33,7 +33,7 @@ entt::locator<interface>::allocate_emplace<service>(allocator, argument);
The difference is that the latter expects an allocator as the first argument and
uses it to allocate the service itself.<br/>
Once a service has been set up, it's retrieved using the value function:
Once a service is set up, it's retrieved using the `value` function:
```cpp
interface &service = entt::locator<interface>::value();
@@ -58,13 +58,13 @@ Finally, to reset a service, use the `reset` function.
## Opaque handles
Sometimes it's useful to be able to obtain a _copy_ of a service to be assigned
to a different locator. For example, when working across boundaries it's common
to _share_ a service with a dynamically loaded module.<br/>
Sometimes it's useful to _transfer_ a copy of a service to another locator. For
example, when working across boundaries it's common to _share_ a service with a
dynamically loaded module.<br/>
Options aren't much in this case. Among these is the possibility of _exporting_
services and assigning them to a different locator.
This is what the `handle` and `reset` functions allow to do.<br/>
This is what the `handle` and `reset` functions are meant for.<br/>
The former returns an opaque object useful for _exporting_ (or rather, obtaining
a reference to) a service. The latter also accepts an optional argument to a
handle which then allows users to reset a service by initializing it with an
@@ -82,7 +82,7 @@ uninitialized service elsewhere as well.
Note that exporting a service allows users to _share_ the object currently set
in a locator. Replacing it won't replace the element even where a service has
been configured with a handle to the previous item.<br/>
In other words, if for example an audio service is replaced with a null object
to silence an application and the original service was shared, this operation
won't propagate to the other locators. Therefore, a module that share the
ownership of the original audio service is still able to emit sounds.
In other words, if an audio service is replaced with a null object to silence an
application and the original service was shared, this operation won't propagate
to the other locators. Therefore, a module that share the ownership of the
original audio service is still able to emit sounds.