Comments (3)
Current places StewardData is required:
- For the base time type
- For Event types
- Inside DataHandle, and Globals; and because of this, DataHandle, EventHandle, and DataTimelineCell themselves must implement it
- For queries and query results, and therefore SimpleTimeline data
Also, DataTimeline itself DOESN'T require StewardData as a supertrait, which is worth reconsidering.
And the supertraits required by StewardData:
- Any (I'm not worried about this one)
- Clone. Surprisingly, this is not currently very required for base times – we only explicitly clone them while mucking about with ValidSince and other API stuff, and I think it could all be done by requiring the user to pass in Time instead of &Time. However, there's no reason NOT to require Clone for Time. Queries definitely want Clone so that values can be stored for auditing, although that might be modified somehow by query-by-reference. DataTimelineCell actually wants to NOT implement Clone, because cloning them is weird about history, so DataHandle innards and Globals want to not require it as well. DataTimeline requires Clone at the moment, although I don't think we really want to be cloning it except maybe for auditing. We never clone Events, and there's not much need to clone them for auditing because they're immutable.
- Eq. This requirement is irrelevant for Time because Time has to be Ord anyway. Queries need it for auditing purposes. It would be weird on DataTimeline, and not helpful for auditing because differing speculative futures are permitted. Implementing it for DataHandle innards MIGHT have a use for auditing, but it's weird because they can contain DataTimelineCells. (Currently, DataTimelineCell does Eq by unique id, so Eq between 2 different objects containing them would always be false.) Event should probably follow along with the other simulation data types.
- Serialize (+ DeserializeOwned): Time, Globals, Event, DataTimeline, and DataHandle innards obviously need this for actual serialization. Queries don't necessarily need it, although I think I should require it for future-proofing in case I want to share queries across a network for auditing purposes.
- Debug (I'm not worried about this one)
Also, PersistentlyIdentifiedType ISN'T required by StewardData, which is worth reconsidering. Time and Globals don't need it, although I might want to stick Globals behind a DataHandle, which would require it. Events and direct innards of DataHandle require it for serialization. Queries and query results will need it if they want to be able to use Serialize.
In summary (including only the disputed traits; ! means "definitely not required", not "required to not have it"; DeserializeOwned is automatically included with Serialize):
Time:
Clone + ?Eq + Serialize + !PersistentlyIdentifiedType
Event:
?Clone + !Eq + Serialize + PersistentlyIdentifiedType
DataTimeline:
?Clone + !Eq + Serialize + !PersistentlyIdentifiedType
Globals:
!Clone + !Eq + Serialize + ?PersistentlyIdentifiedType
DataHandle generic parameter:
!Clone + !Eq + Serialize + PersistentlyIdentifiedType
Other stuff often used inside DataHandle:
!Clone + !Eq + Serialize + !PersistentlyIdentifiedType
Queries and query results:
Clone + Eq + ?Serialize + ?PersistentlyIdentifiedType
from time-steward.
In conclusion, I don't see any real pattern here. There is no call for a single "StewardData" trait to unite all of these uses.
HOWEVER, we do need some form of abbreviation – it's pretty bad to have a long list of traits that's repeated in a lot of places, especially if you eventually decide you need to add or remove a trait from the list. So I propose that each long list of traits be abbreviated into a single trait, with a blanket impl.
trait BaseTime: Any + Debug + Send + Sync + Clone + Ord + Serialize + DeserializeOwned + Hash {}
trait SimulationStateData: Any + Debug + Serialize + DeserializeOwned {}
trait Query: Any + Debug + Clone + Eq + Serialize + DeserializeOwned + PersistentlyIdentifiedType {}
trait QueryResult: Any + Debug + Clone + Eq + Serialize + DeserializeOwned + PersistentlyIdentifiedType {}
DataTimeline and Event are already traits, so their lists of supertraits already don't need to be repeated everywhere.
from time-steward.
Note: normally, Serialize + DeserializeOwned + !Clone
types are a little weird because serializing followed by deserializing is a de facto clone. However, in this case, the Serialize impls aren't actually available in all cases – DataTimelineCell and the handles panic if you try to serialize them in any context other than the "serialize the whole simulation state" context.
from time-steward.
Related Issues (20)
- Standardize using ExtendedTime rather than base time in all API functions HOT 2
- Rethink valid_since() and forget_before() API HOT 3
- For the types that can only be dereferenced using a TimeSteward, is there any 0-cost way we can provide safety against using the WRONG TimeSteward object?
- Use a faster hash algorithm? HOT 1
- Implement Rand for DeterministicRandomId HOT 1
- Support upper time limits for step()
- Put the "rowless" code at the top level, since it's almost as complete as the old code
- Tracking issue for current very-disruptive API changes HOT 1
- Figure out what I really mean by StewardData [duplicate] HOT 1
- Make better manual Debug impls
- Modification protocol HOT 1
- When generic associated types become available… HOT 1
- Single-threaded incremental serialization?
- Implement Div<i64> and variants for Range
- Make Predictions have an independent existence
- Make a robust collection of trajectory types
- Make undo implementations implicit
- Rename Basics HOT 1
- Fast paths for DataTimeline modifications HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from time-steward.