Defining dynamic but consistent types
See original GitHub issueThe FooByUser object is a simple structure representing the amount of foo performed by each user, setting each property’s key & value to the username & recorded foo respectively.
The collection of keys composing the object may vary between objects representing different periods. For example if new user3 records foo in April then the March and April objects will differ in keys : {user1: 100, user2: 3}
vs {user1: 87, user2: 5, user3: 30 }
.
From a code documentation perspective I want to define FooByUser as having a set of property keys of known origin & type (if such a word can be used), but which cannot be predetermined for each particular instance.
Could we have a syntax something like the following?
interface FooByUser {
*<username>: Number
}
def username {
desc: "The username of a user",
source: {type: "database", location: "users.id"}
}
Where the <> demonstrate that that we are using a def
rather than a static key and the * represents that there may be more than one of these keys.
Issue Analytics
- State:
- Created 7 years ago
- Comments:14 (4 by maintainers)
Top GitHub Comments
Whenever we can we will provide something that is familiar.
Concerning the declared intents, I am not inclined to edit these: Eric is the one who knows what he envisioned originally. You can do a PR though.
It sounds like what you really want is a generic collection, where we don’t care about the names of the keys at all. You could implement such a collection that shares some convenience methods from Arrays using #120:
Would that work for your usecase?