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
If they were the same, we could create a BarcodeGeneratorInterface, and each generator could implement it. I think that'd be better than simply extending the abstract class.
What do you think about creating a version 3 uses an interface and requires that $foregroundColor is a string in all the generators?
The text was updated successfully, but these errors were encountered:
What do you think about creating a version 3 uses an interface and requires that $foregroundColor is a string in all the generators?
Yes, that could work. Lots of these issues are legacy from 10+ years of this code' existence. Bit by bit we modernise it, which is nice.
For version 3 I am also thinking about pulling the BarcodeTypes and Generators further apart, where you can inject the results of a BarcodeType into a Generator (but with different names). That way it is easier to build or tweak your own generator. A better interface could also help with that.
In the PNG generator, the signature is
But in all the others, it's a string
If they were the same, we could create a BarcodeGeneratorInterface, and each generator could implement it. I think that'd be better than simply extending the abstract class.
What do you think about creating a version 3 uses an interface and requires that $foregroundColor is a string in all the generators?
The text was updated successfully, but these errors were encountered: