@quenty/servicebag 6.7.0 → 6.8.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -3,6 +3,14 @@
3
3
  All notable changes to this project will be documented in this file.
4
4
  See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
5
5
 
6
+ # [6.8.0](https://github.com/Quenty/NevermoreEngine/compare/@quenty/servicebag@6.7.0...@quenty/servicebag@6.8.0) (2023-06-24)
7
+
8
+ **Note:** Version bump only for package @quenty/servicebag
9
+
10
+
11
+
12
+
13
+
6
14
  # [6.7.0](https://github.com/Quenty/NevermoreEngine/compare/@quenty/servicebag@6.6.1...@quenty/servicebag@6.7.0) (2023-05-26)
7
15
 
8
16
  **Note:** Version bump only for package @quenty/servicebag
package/README.md CHANGED
@@ -104,4 +104,34 @@ function DialogPane.new(serviceBag)
104
104
  self._dialogInput = DialogInput.new()
105
105
  self._maid:GiveTask(self._dialogInput)
106
106
 
107
- ```
107
+ ```
108
+
109
+ ## Classes versus singletons
110
+
111
+ Right now services and classes aren't the same. There's no contract to transform a class with lifetime
112
+ into a service. However, because some of our services actually implement a .new() method (i.e. service definitions can be classes), we can't differentiate easily.
113
+
114
+ The issue is around life-cycle.
115
+
116
+ 1. Service.new() can either be a constructor which establishes just data for the service or...
117
+ 2. Service.new() can actually establish state data.
118
+
119
+ Other service providers solve this issue by doing the following...
120
+
121
+ 1. Separating out the service identifier from the actual service definition (interfaces)
122
+ 2. Separating out the addition of services from the actual services
123
+
124
+ We inherently don't want to separate out interfaces yet because we don't know what the actors or tie-interfaces for hot reloading will even look like.
125
+
126
+ It's important that we don't define this yet because there's a good chance separation at the service layer will be very important (i.e. we'll want to observe service state existing).
127
+
128
+ ### Potential solution: Interface provision
129
+
130
+ We could establish a contract that providing an interface will be allowed. That is, a service can return a value it'd like to use as an interface instead. We may need to wait until we resolve these other problems first.
131
+
132
+ ## Major changes in the future
133
+
134
+ 1. Require-by-name
135
+ 1. Interfaces as definition
136
+ 2. Hot reloading
137
+ 3. Async interfaces
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@quenty/servicebag",
3
- "version": "6.7.0",
3
+ "version": "6.8.0",
4
4
  "description": "Service providing mechanisms for Nevermore",
5
5
  "keywords": [
6
6
  "Roblox",
@@ -33,5 +33,5 @@
33
33
  "publishConfig": {
34
34
  "access": "public"
35
35
  },
36
- "gitHead": "11058e90e51ea83d3dad6ae9abe59cc19c36b94b"
36
+ "gitHead": "5d8f00296517b2a1aff2db540728f5e689a0c3e3"
37
37
  }