Userdata support #52
Replies: 8 comments 71 replies
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
A prior commit for the implementation passed a table that contained the buffer, position, and size. Going from that version to now, there was a performance improvement from passing each individually. I could revert in order to improve the user experience. On the note of safety, the userdata functions can already cache the buffer or mess with the data. Modifying the table to have unnecessary values, or a metatable, is not a concern relative to the buffer. On the note of likelihood, it is unlikely that this concept will be reconsidered. The experience is not all around better by passing a table. There are other ways, like adding the size and position condition to inflate. |
Beta Was this translation helpful? Give feedback.
-
|
We propose the addition of two functions to the public API. type SupportUserdata = (record: {
-- tag number must be between 0 and 255 (or it will be morphed into a corresponding 0-255 value)
tag: (userdata)->number?,
serialize: (userdata, tag: number) -> any?,
deserialize: (data: any, tag: number) -> any?
}) -> ()
-- bs.supportUserdata
type IsSupported = (userdata) -> boolean
-- bs.isSupportedFor
We also propose the removal of readers/writers and their corresponding methods in the internal userdata API. Instead of the user needing to get the reader/writer function and call it when their case does not support a userdata, we will internally take on that responsibility. As such, the getter functions will not be exposed. As such a new internal function will be added that provides the capability to clear the supported userdata. type ClearSupport = (keepNLastest: number?) -> ()
-- userdata.clearSupport |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
Fresh view, not looking at anything else in this thread until this reply is complete. How do we know a userdata is supported and how do we treat unsupported userdata? We currently cannot know when a userdata is or isn't supported until it has passed the function and even then we cannot be certain. We also don't know what to do in situations where the userdata isn't supported. We are using different userdata to represent NIL, which should be renamed to UNSUPPORTED. Is there a reason for it producing different userdata? I may have prior used it to differentiate unsupported userdata, however I believe that unsupported userdata will not be used. In my case, I merely store unsupported userdata since I don't want to reconstruct the entire structure to remove them. In fact, if they share a userdata, one could say When userdata writers are provided and a userdata is unsupported, what should occur? The user should return the respective values, all being equal, then we rewrite the CUSTOM byte into UNSUPPORTED. However, currently we write CUSTOM UNSUPPORTED. It takes away a bytecode that users may need and is unintuitive. |
Beta Was this translation helpful? Give feedback.
-
|
Inflate is necessary for userdata, should it be externalized? The same goes for the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What would users need when working with userdata?
Would users like a reference to the existing table, should the userdata be within a table?
Beta Was this translation helpful? Give feedback.
All reactions