3 ms·
Interesting idea! As an example, if the template was "<span>{name}</span>" then if I follow you correctly, it would generate some `Model` struct/interface/what
by tubthumper8 3y ago
Interesting idea!
As an example, if the template was "<span>{name}</span>" then if I follow you correctly, it would generate some `Model` struct/interface/whatever that would have a `name: String` field.
I think a problem comes about when it's instead:
"<span>{itemCount}</span>"
Obviously it can't know that this intends to be an integer. Would it generate an `itemCount` field that is something generic like "impl Display"? Or still String? Either way, you may have other logic that needs this `itemCount` as an integer, for arithmetic or something. Perhaps two models, both auto-generated for all String fields but one you don't touch and the other you can change fields as long as they're convertable to String.
I think the main problem is going from a more structured to less structured (model to template) is possible but going the reverse way (template to model) can't always infer the structure.
- jitl 3y agoWell, you’d need to express the types of the arguments your template expects, and then your template type system and your host language type system need to agree on those types, and now you need to code-gen the host language struct type from the template args type - but what’s the point? It’s still needless toil in my view. Just write a function in the host language, it already has a great way of expressing the types of arguments passed to a function (hopefully)
- usrusr 3y agoTemplates would of course have to define types, at least where string wouldn't be considered good enough. Also names for repetitions and optional blocks. It would not solve any big problems when you start with a detailed plan and everything is going according to it. Perhaps that's the reason why fragile expression languages are so often considered good enough: it cements the importance of the person writing the spec (sorry for the sarcasm)