-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Custom Printing Broke Regular; Should Be Avail. to All Units #21
[Bug]: Custom Printing Broke Regular; Should Be Avail. to All Units #21
Conversation
seandenigris
commented
Sep 9, 2020
- All tests now pass. Neglected to run all tests before submitting the custom printing hook, so new test passed, but existing ones failed.
- While we're at it, push up the hook into SimpleUnit so that DerivedUnits can take advantage of it; add a test for this
- All tests now pass. Neglected to run all tests before submitting the custom printing hook, so new test passed, but existing ones failed. - While we're at it, push up the hook into SimpleUnit so that DerivedUnits can take advantage of it; add a test for this
Pull Request Test Coverage Report for Build 83
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @seandenigris , thanks!
I'm intrigued about what subclasses you're creating. We're have been using it heavily for years now and, I don't remember creating any single subclass. For cents i.e we'll have a base unit and cent derived from it.
dollar := BaseUnit named: 'dolar' sign: '$'.
cent := ProportionalDerivedUnit baseUnit: dollar conversionFactor: 1 / 100 named: 'cent'.
I'm just curious.
Did you evaluate adding this message to UnitBehavior
?
Thanks for the feedback, @fortizpenaloza!
I was creating a money package. I wanted to flesh it out a bit before release. Maybe I'm using it wrong (i.e. in a non-standard or inefficient way)? I have e.g.:
No. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with merging this changes now to fix the tests and open an issue to better think if we should move something to UnitBehavior
No, it is ok. We use formatters to print measures. I guess it didn't occur to me that it could be done this other way because I'm so used to working with the library the other way.
Can you open an issue as @gcotelli proposed? |
I'm intrigued by this, @fortizpenaloza. Is there any publicly available code I can look at to understand this approach better? |
|
No, just this one https://github.com/ba-st/Buoy/blob/6d01b2e41caba920e1c4edd2fe4933b219234e5b/source/Buoy-Collections/CollectionFormatter.class.st The simplest way to explain it is that printing is presentation logic. So, the #printOn: is just used in inspectors. Printing these objects into web views or reports requires, at least for us, many ways to represent them. And since we avoid mix presentation logic into our model, we encapsulate these into formatters. For example, a price formatter collaborates with a locale (usually the user') to decide where to put the sign. If after or before. And, you can instantiate it configured to show as many decimals as you want. The context of these decisions is a huge financial application were classes are count by thousands. I'm telling you this because your approach maybe is good enough for you 😊 |