On Nov 15, 2007 11:01 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Nov 15, 2007 10:42 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
This is totally different from a design perspective. Dan mentioned a generic mechanism to write, where as you're suggesting a unique operation. A generic, public interface to modify and write to the DB is, in my opinion, a bad idea, but operations which do things (and write) within libalpm's control is fine
I actually wasn't referring to mutators to make that clear. I was thinking along the lines of a public alpm_pkg_force_write(pmpkg_t *pkg) or something. However, that still doesn't seem that clean, but I don't know.
Right, I was using that as an example... let me spit out more. This here: alpm_change_install_reason(pkg); is superior to: alpm_pkg_set_reason(pkg, 1); alpm_pkg_write(pkg); because it puts the _operation_ in our control. It's about "use cases" and all that fun crap 8) I don't think we want to expose the ability to modify the database with public functions in libalpm, but an operation that just happens to modify it is different.