Extension support #54
Replies: 2 comments 1 reply
-
|
There is also the problem of priority. Some extenders want their feature to be checked first, whereas others are last. There are even cases where the extendor wants to store profile information, or any additional information for that matter. Such as metatables. |
Beta Was this translation helpful? Give feedback.
-
|
We cannot support extenders enough without considerable regressions to performance when an extension exists. Extenders seldomly update their bs version since they modify the internals to further reduce output size for highly specific criterium. Multiple extensions would have priority conflicts, as a prior reply stated. I shall decline this idea. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Could we make it easier for extenders to add their own features w/o needing to modify the internals?
What about within link we allow for:
link.extension(number, Reader)The reader function is called whenever the extension number is hit.
I cannot think of an adequate approach for writer. We could have some sort of condition function and a writer function that is called after the conditional and after the number is written to the buffer. The issue is that it becomes incredibly slow to check each condition.
This would mean that userdata is a built-in extension with the condition that
type(value) == "userdata".Beta Was this translation helpful? Give feedback.
All reactions