On Sun, 2008-04-27 at 20:59 -0400, Marty Alchin wrote: > I'm a bit on the other side of the situation here. To me, save() seems > adequately ambiguous, either inserting or updating depending on the > situation. As an alternative, I'd think having separate methods, like > create() and update() would make things clearer still. > > In addition to avoiding the whole argument-naming issue, it seems like > this would make subclassing even better. If you create a subclass and > override create(), that would be used in the explicit create() case as > well as the create side of the save() case.
Why do people want to add a whole extra function call when a simple parameter will do? All the main logic is going to be in one place anyway (unless you like having masses of duplicated code). With a parameter it's a simple if-test to pick the right branch. With a whole extra method, you end up calling something that takes the parameter anyway that does the whole extra if-test. So all you've done is introduce a function call under some dubious justification that people might want to screw up create() and update() independently. They can already do that; they don't need an officially blessed way. -1 on adding extra methods. This situation just isn't needed that often. You're mostly just going to call save() with no parameters; it's the right thing. For the rare cases, we give you micro-control (we need this internally sometimes). Malcolm -- I intend to live forever - so far so good. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
