undefined | Better HN

0 pointsmunk-a1y ago0 comments

I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.

0 comments

3 comments · 1 top-level

hamandcheese1y ago· 2 in thread

If you are replacing a performant property with a slow network call, you are being negligent if you aren't reviewing all the callers to make sure that is okay.

hparadiz1y ago

In a typical ORM when you do say $Model->DateTime = 1732046457; the __set is actually checking the value and seeing oh it's an integer. Treat this as a unix timestamp. But when you run save() the query is actually converting that to a Y-m-d H:i:s (for MySQL/MariaDB). This doesn't actually happen until you run save() when it makes the query and runs the network call. Most of that time it's actually storing everything in memory.

But you might want to support string date times and the PHP object DateTime as well. So a typical well designed ORM converts multiple PHP types into a SQL string for saving. That's what the historical __set and __get are all about. This is called "mapping" by most ORMs and a very well designed modern one like Doctrine will actually have mappings for different SQL storage engines available.

Obviously it also has to handle the reverse.

hamandcheese1y ago

That is a fine argument for setters, but I still don't see the connection between that, and the desire to disguise properties as setter methods.

2 more replies

j / k navigate · click thread line to collapse