That would be great, assuming enough people agree with that table’s opinions :p
These are guidelines anyway, and the “consider using” is appropriate. There are some caveats though, in particular regarding efficiency. Last time I checked (some time ago), sets were much slower than hashes. An assoc list can have a very different performance than a hash which keys are lists.
Also: “A hash whose keys are symbols or strings —> A record” Only for fixed keys that are known in advance
Not sure about this one either: “A list of symbol-keyed hashes —> A table”
But what would be even better is a table listing the properties of the different data structures (in particular in O notation)
Both tables would be good. Property tables are great for comparing data structures. “Use this instead of this” tables are great for reviewing code. Straightforward substitution guidelines are easy for people to wrap their heads around.
Agreed.
It is possible to dynamically build and use Rebellion records with arbitrary keys. (But I’d gladly take a dedicated reducer and a for form over keyword-apply)
But if you add a key, you need to make a new record type, right?
(I haven’t used them, I merely looked at the docs)
Rebellion has a record data type that is essentially a hash table keyed by keywords.
It’s a separate notion from define-record-type
Aha! I hadn’t seen this, thanks. A little ambiguous maybe, this might need some clarification @notjack :slightly_smiling_face:
Although this still mentions: > Use records instead of hash tables when keys are expected to be literal names written in source code. which doesn’t cover my usecase where I read keyword hashes from files then
As I hinted earlier, you can use keyword-apply to build records with arbitrary keys. However, proper support for dynamically building records is a future feature, if IIRC.
I think I’ll stick with symbol hashes :slightly_smiling_face:
rebellion/collection/record was one of the first things I made in rebellion, so, it’s not as worked-out as the other bits
and I’m less sure it’s a good idea now
I was thinking rebellion/collection/record could be used to build a library for row types. But I suppose that such a thing could be build on top of rebellion/type/record.