-
Notifications
You must be signed in to change notification settings - Fork 19
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit and the one before it attempt to coalesce building a resource and registering it, since you need similar information for both operations. I really like one thing about this approach: Discrete primitive resources get value mappers by default, meaning they "just work" with little to no additional configuration. There are a few things I don't like about this approach: 1. Writing the builder is tedious and repetitive, since I'm writing one for each kind of resource (discrete, Polynomial, clock, etc.). It strongly feels like most of this behavior could be moved up to a higher level of abstraction, somehow. 2. This makes registration of MutableResource quite different from registration of "regular" Resources. Relatedly, specialized MutableResource constructors now need to either use the builder or return the builder, both of which feel wrong. You're either leaking an abstraction that you likely shouldn't be, or you're restricting the modeler in an awkward, artificial way by making all the builder choices for them. Or, you end up bloating the special-purpose constructors too much to expose all the builders' functionality. 3. Relatedly, for things like Polynomial resources, where we often register an approximation, it feels like we should handle that akin to discrete. But we can't, strictly, since what we register and what we return are different. Building the choice of approximation into this class feels wrong. It suggests that if you build the way to register into the resource construction, it ought to be general enough to apply to any resource, not just polynomial / discrete. 3. Passing the registrar to the builder now feels awkward. I think maybe the registrar should become a singleton we access at-will, like the Logger. Alternate designs include: 1. Making a general resource builder, and letting particular kinds either sub-class that builder or write helper methods that fit the arguments of that builder. For example, the general builder accepts a ValueMapper<Dynamics>, and discrete resources could offer a function from ValueMapper<T> to ValueMapper<Discrete<T>>. The awkward bit here (maybe?) is registration, as most resources can't be registered. Only discrete and linear can be. However, point 3 above suggests if we expand our notion of registration to include a mapping step, maybe anything could be registered, they just aren't by default... 2. Get rid of the builder altogether, and instead lean on that "helpers that build the arguments of your general constructor" pattern *hard*. This is what we had in streamline up to this commit, and it works well without tons of boilerplate code to maintain. Maybe we could just make the registrar smarter, such that it can at least pull the name out of Naming. For more consistency, we could even remove the regsitrar constructor that takes a name, and ask users to directly invoke it like `register(name(r, "newName"), ...)` if they want to change the name. If we really wanted to lean even further in that direction, we could register the value mapper for discrete stuff like we register the name, in a third-party class like Naming, and have the registrar pull it from there. Then you'd say something like `register(serializable(name(r, "newName"), mapper))` to get the full behavior. 3. Maybe we could return InconBehavior<MutableResource<...>> instead of just the resource itself? If you do that, I think you could at least push the choice of how to save the resource out of the constructors, and make it a post-step where you choose notSaved or serialized. Then if you want to share information between that choice and registration, maybe DiscreteResources could offer helper methods for the most reasonable combinations? I.e., something that chooses serialized + registered with the same information? It still feels different from other kinds of registration in an awkward way... After working through these options, I'm leaning towards option 1, keep a resource builder as a place to centralize saving and registration together, but lift it to MutableResource in general. Then, methods like DiscreteResources.discreteResource could instantiate a builder with more default options chosen, but still expose the full generality. With a little care, they might even be able to return a sub-class of the general builder, with additional convenience methods exposed...
- Loading branch information
David Legg
committed
Oct 30, 2024
1 parent
b20c1b4
commit 959b577
Showing
5 changed files
with
165 additions
and
63 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.