> This is what people normally do (unpack just the values they need, > when they need them). Due to the fact that there hundreds of format-strings which dynamically compiled from a more verbose language at runtime, we will have significant complexity in the code in order to generate format strings that parse just the fields that are needed for filtering. It's not just put-a-string-here-and-there. > I don't think there is a net win from adding complexity to the struct > module. Introducing lazy behaviors creates its own overhead > that would compete with code optimized using the traditional > approach (unpack what you need, when you need it). Also, > the new behaviors add to the cognitive load when learning > and remembering how to use this module. The complexity is very well handled. Remember that the interface to the module does not change at all and the documentation would be exactly the same. There is no special case introduced here the user has to know about. I also think this case has very little black magic in it since we are dealing only with immutable objects and do not have delayed error conditions (both usually being the primary source of headaches when introducing lazy behavior).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4