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
{{ message }}
This repository has been archived by the owner on Nov 13, 2021. It is now read-only.
Considering the interface type Pdf should have all of the methods that are defined in Fpdf (which also then automatically get added to Tpl) would it make sense to make Fpdf and Tpl un-exported types and return a Pdf interface instead? I feel like this could simplify things from a user perspective.
I do understand however that this would be a breaking change so you likely won't want to do it, but I figured opening up a discussion about it wouldn't hurt.
The text was updated successfully, but these errors were encountered:
Interesting thought. Would there be advantages to not exporting Fpdf and Tpl besides just information hiding? If not, maybe they could remain exported but we could still use the Pdf interface wherever possible. If I am not mistaken, doing this would not break anything.
I think New() would still return the concrete type *gofpdf.Fpdf and CreateTemplate() would still return *gofpdf.Tpl, but functions like StateGet(pdf *Fpdf) could be changed to StateGet(pdf Pdf). The idea would be to honor Postel's Law (in Go: “Accept interfaces, return structs”).
Considering the interface type Pdf should have all of the methods that are defined in Fpdf (which also then automatically get added to Tpl) would it make sense to make Fpdf and Tpl un-exported types and return a Pdf interface instead? I feel like this could simplify things from a user perspective.
I do understand however that this would be a breaking change so you likely won't want to do it, but I figured opening up a discussion about it wouldn't hurt.
The text was updated successfully, but these errors were encountered: