I recommend going further than this example and don’t just store the value/currency for your price. You should also store the VAT. And generally anything else that involves division or percentages.
Jump through whatever hoops are necessary to work exclusively with addition and subtraction (and the occasional cheeky multiplication to shortcut repeated addition operations). Percentages and division is where people tend to get into trouble.
Specifically you should avoid the last line of code in this example from the article OP posted:
I’m not sure what they were trying to get at with that example, so here’s a more realistic example where of avoiding percentages:
<span style="color:#323232;">class Product {
</span><span style="color:#323232;"> /**
</span><span style="color:#323232;"> * The price of the product excluding tax. Entered by the user into the database.
</span><span style="color:#323232;"> */
</span><span style="color:#323232;"> public Money $price;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> /**
</span><span style="color:#323232;"> * The amount of VAT to collect for this product. Not entered by the user, but calculated
</span><span style="color:#323232;"> * whenever the product price changes (or, whenever the tax legislation changes). The
</span><span style="color:#323232;"> * value is stored in the database as an integer (and currency).
</span><span style="color:#323232;"> */
</span><span style="color:#323232;"> public Money $vat;
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">class CartItem {
</span><span style="color:#323232;"> public Product $product;
</span><span style="color:#323232;"> public int $qty;
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;">$invoiceTotal = new Money(0);
</span><span style="color:#323232;">$invoiceVat = new Money(0);
</span><span style="color:#323232;">$paymentAmount = new Money(0);
</span><span style="color:#323232;">
</span><span style="color:#323232;">foreach ($cartItem in $cart) {
</span><span style="color:#323232;"> $invoiceTotal
</span><span style="color:#323232;"> ->add($cartItem->product->price)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> $invoiceVat
</span><span style="color:#323232;"> ->add($cartItem->product->vat)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> $paymentAmount
</span><span style="color:#323232;"> ->add($cartItem->product->price)
</span><span style="color:#323232;"> ->add($cartItem->product->vat)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">}
</span>
Avoiding division should also be done everywhere else - for example if your credit card facility charges 30c + 2.9%… don’t fall for the trap of calculating 2.9% of $paymentAmount because chances are you’ll round something in the wrong direction. Also, some cards have higher fees. Instead, when you authorise the payment the credit card facility should tell you that the card fee for that actual transaction is 152 cents. Record that number in your payment record and use it for your own internal reporting on profits/etc.
This. Can people please stop posting medium articles?
Medium goes against basically everything Lemmy/etc stands for. It’s also just a shitty experience, for example code is rendered in a large font and cropped a 650 pixels without any wrapping. Yuck.
If I remember correctly people said Medium is very limiting and confusing when it comes to ownership of your content.
It seems they can re-use (as in publish) your original content elsewhere, like publishing it in a book.
What I especially dislike is the registration enforcement (register! Use our App! Become a member!).
There are some sources in my feedreader from Medium and they become less and less usable.
Something I stumble upon more often recently is Substack. Actually intended to be a tool for offering paid content and a newsletter publishing tool, I think, but the user experience is much more pleasant. They ask me to subscribe to the publisher’s newsletter each time, but don’t prevent me from going further, if I decline.
Also getting some attention recently is the indieweb movement. People intentionally publish on their private websites, running on various different platforms and techniques. It’s quite interesting to observe and it seems there is a focus on a more tech-savvy audience and publisher group, but I might be wrong.
Just because one person said “final is bad”, the Laravel fanboy herd is flocking to solutions like this. In my opinion, the package per se is not bad, but the unreflected, absolute statement “final is bad” is the problem.
In my opinion, the package itself is bad. It suggests by its very existence that final is bad. It tempts to use dependencies in a way that was not intended by their developers.
For multiple entities, it’s cleaner and more beginner-friendly than using the #[MapEntity] attribute (which is still an option).
And imo it’s a good move to deprecate “not passing the mapping” even for single entities. With the mapping the behaviour is more intuitive and “feels” less magic.
You’d probably get more feedback if you posted a proposed solution (or “correct answer”) to StackOverflow and let the community tell you how dumb you are in between generating exactly what you are looking for.
Real answer: consider passing Markdown through instead. You’re getting really close to one of my favorite memes. It’s a dark path, don’t tread down it.
“Master” is a strong word, but when I have to build applications it’s PHP in the back and JS up front. Specifically, Laravel implementations with whatever on top.
I’m extremely proficient with templating languages that eventually turn into HTML (nunjucks, antlers, blade, handlebars, webc, vue) and CSS (SCSS, LESS). A ton of my work winds up being on Static Site Generators and the unholy abomination that is at-scale Email development.
php
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.