3 ms·

Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() I had no idea that New Zealand was a city! Can I a

Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() I had no idea that New Zealand was a city! Can I ask how the cities of Cambridge and New Zealand are related, though? Is one like the billing city and the other the shipping city?

eurleif 13y ago
So use keyword arguments if you really find that so confusing: >City(name="Cambridge", country="New Zealand").save() Doesn't change the point about SQL.
- rmrfrmrf 13y ago
  Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code? So now you have me going and editing tested, working code just for my personal preference and digging through code that I may or may not be authorized to view. Do you have any other best practices to share?
  - rtpg 13y ago
    Couldn't that argument be used about any function that has multiple values? Besides, keyword arguments do solve the problem. Also, correctly named variables ( City(city_name,country_name).save() ) and , if need be, some comments all solve this issue.
  - mercurial 13y ago
    > Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code? Spoken like someone who never had to deal with recordsets of 40 different values, accessed by position, passed around various functions... ORMs can be a problem, in the sense that complex queries may be harder or impossible to express, and there can be a cost in terms of performance. Snark over keyword arguments, which are completely orthogonal to ORMs, is both rude and misplaced.
  - Daishiman 13y ago
    You'll be looking at the code for a first time just once; you want to optimize for the guy who spends a nontrivial amount of time on code. Furthermore, ORM queries a much more readable, and the OP's example is bad; Django ORM queries use keyword arguments all the time.

eurleif 13y ago

So use keyword arguments if you really find that so confusing: >City(name="Cambridge", country="New Zealand").save() Doesn't change the point about SQL.

rmrfrmrf 13y ago
Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code? So now you have me going and editing tested, working code just for my personal preference and digging through code that I may or may not be authorized to view. Do you have any other best practices to share?
- rtpg 13y ago
  Couldn't that argument be used about any function that has multiple values? Besides, keyword arguments do solve the problem. Also, correctly named variables ( City(city_name,country_name).save() ) and , if need be, some comments all solve this issue.
- mercurial 13y ago
  > Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code? Spoken like someone who never had to deal with recordsets of 40 different values, accessed by position, passed around various functions... ORMs can be a problem, in the sense that complex queries may be harder or impossible to express, and there can be a cost in terms of performance. Snark over keyword arguments, which are completely orthogonal to ORMs, is both rude and misplaced.
- Daishiman 13y ago
  You'll be looking at the code for a first time just once; you want to optimize for the guy who spends a nontrivial amount of time on code. Furthermore, ORM queries a much more readable, and the OP's example is bad; Django ORM queries use keyword arguments all the time.