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
-
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
String
where it's not actually needed:That results in needing to explicitly
.to_s
a 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_s
What do you think about adding an overload method which calls .to_s on the
content
?The
.to_s
is naïve, but it'll result in not needing to manually call.to_s
on 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_s
as well.Beta Was this translation helpful? Give feedback.
All reactions