News for hackers. Stuff that matters.
Re:Flyweight: An ORM for SQLite by JustLurking2022 on Saturday October 01, 2022 @06:32PM (#33050780)
Ummm... No. See my previous comment - at least in Rails, the queries aren't part of the data object themselves, but are instead mixins or default handlers (don't recall which offhand), so it's really just syntactic sugar that makes it appear as though they are methods on the data class.

Even if they did the same thing you're suggesting, by that logic, we should all use PHP because WordPress does, and it's probably more popular than those two combined.

Take a look at something like Spring or Entity Framework to see other takes on ORM patterns.

And again, you're trying to argue against ORMs, while citing that your suggested alternative is supported by the way ORMs do it.

Re:Flyweight: An ORM for SQLite by ajgrover on Saturday October 01, 2022 @06:38PM (#33050830)
I’m not the person that suggested handwriting object methods. As I’ve said, I agree with the point you’re making, I’m not arguing with you, or for any specific ORM design.

I don’t see what the nuance is you’re getting at with the mixin vs object method argument though. They both have the same issues around testability and violation of SRP.

Re:Flyweight: An ORM for SQLite by JustLurking2022 on Tuesday October 04, 2022 @01:34PM (#33083760)
Ahh, apologies misread the tree. In terms of the nuance around a mixin vs object - a mixin can be defined and tested in its own separate library independent of your data model, so it's at least cleaner in terms of separation of concerns.
Re:Flyweight: An ORM for SQLite by ajgrover on Tuesday October 04, 2022 @01:41PM (#33083876)
That’s fair. My issue with the mixin approach is that then your app code can hit the database from anywhere you have access to the model object, which makes testing your own code in isolation much more difficult