String tags with cache #5
Open
Conversation
This file contains hidden or 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 patch makes two changes: it caches the return values by tag, and auto-converts a string tag into a private table. The combination of these means that any module can call something like ```lua local coro = coromake 'scheduler' ``` And will obtain the same nested coroutines table, without running into a problem with using `yield 'scheduler'` somewhere as a literal value. Which is visible in the example, but the silent bug is when the string slips into some process or collection.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes the library so that string tags are auto-converted into a private table, and so that the return
coroutinetable is cached by tag.The combination means that a user can get a consistent set of nested coroutine tools by string, from any module:
Will return the same
corofor any unique string, without causing trouble if that string is yielded by this or anotheryieldfunction.The alternative in the original code would involve either making global or passing around, some common table used only for this purpose, or choosing some metatable or function deemed unlikely to be used, and hoping we don't forget.
The original code also allows a string argument, but then will exhibit strange behavior if that string is yielded, ever, and that's the sort of bug no one wants to have. The semantics are unchanged if the argument isn't a string, and I would argue that what this patch does with strings is safer and more convenient.