Replies: 1 comment 4 replies
-
|
@robacarp it makes sense. I will release a new version today with this change. Thanks for the suggestion. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm normally in favor of a strictly typed interface, especially at the boundary layer of a shard. But I wonder if the expressiveness here might actually benefit from loosening it up a bit where content is passed into a tag renderer.
For example this method declaration has a strict argument type signature of
Stringwhere it's not actually needed:That results in needing to explicitly
.to_sa number, where that's unlikely to be actually necessary:# explicit cast of data to string, because the compiler will complain without it plain query.count.to_sWhat do you think about adding an overload method which calls .to_s on the
content?The
.to_sis naïve, but it'll result in not needing to manually call.to_son every non-string which has a reasonable .to_s implementation. Consider this:This type of desired result is the worst case for this style of html templating engine like blueprint or luckytemplate -- it requires a lot of overhead to compile a simple string, and in this case each data point being injected requires an explicit
.to_sas well.Beta Was this translation helpful? Give feedback.
All reactions