You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, various attributes like format_read require a string containing a function name as the argument. A lot of the time, these functions seem to end up being a simple one-liner.
This adds a decent amount of boilerplate overhead, making the underlying data format specification a little more difficult to read (due to tool integration 'noise'). Although the function could be moved to a different part of the pattern file, to somewhat separate data format from integration, the function would then no longer be co-located with the data it's operating on.
I feel things could be cleaner / clearer, if the contents of that function were optionally able to be inlined. This also avoids needing the pattern creator to make sure the function is uniquely named, as well as having to access the data through a (named) parameter.
As a first pass suggestion, inlining simple one-liners could look like:
Multi-line functions might also be able to be supported, if we consider the concept of lambdas and borrowing some of its formatting. We might go from something that looks like:
// == current (with a more complicated function example) ==structDATE{
u16 year;u8 month;u8 day;}[[format_read("read_DATE"),transform("transform_DATE"),format_write("write_DATE"),
...]];fnread_DATE(auto v){return std::format("{}-{}-{}", v.year, v.month, v.day);};fntransform_DATE(auto v){return(v.year*10000) + (v.month*100) + v.day;};fnwrite_DATE(str v){//not many examples of write functions, let's assume...u64 parsed = std::string::parse_int(v,0);DATE result;
result.year = parsed / 10000;
result.month = (parsed / 100) % 100;
result.day = parsed % 100;return result;};
Currently, various attributes like
format_read
require a string containing a function name as the argument. A lot of the time, these functions seem to end up being a simple one-liner.This adds a decent amount of boilerplate overhead, making the underlying data format specification a little more difficult to read (due to tool integration 'noise'). Although the function could be moved to a different part of the pattern file, to somewhat separate data format from integration, the function would then no longer be co-located with the data it's operating on.
I feel things could be cleaner / clearer, if the contents of that function were optionally able to be inlined. This also avoids needing the pattern creator to make sure the function is uniquely named, as well as having to access the data through a (named) parameter.
As a first pass suggestion, inlining simple one-liners could look like:
The text was updated successfully, but these errors were encountered: