On Thu, May 3, 2012 at 12:43 PM, Julian Edwards <julian.edwa...@canonical.com> wrote: > On Thursday 03 May 2012 11:26:11 Jonathan Lange wrote: >> Actually, that wasn't entirely honest. Sorry. Here's what I was >> actually thinking: >> >> I want to continue doing this work incrementally. Before the 'enum' >> suggestion, the way I planned to do it was this: >> >> 1. make a property with the new name; make that a simple >> getter/setter for 'commercial' >> 2. change the permission model for setting both it & commercial >> 3. a series of patches to rename the column in the db >> >> I still think this is a good plan. We could do the enum bit as a step 4. >> >> However, I'm not 100% convinced about the enum. It is more flexible, >> but without an actual use case it's a YAGNI. I also suspect that it > > Enums are nearly always better than a bool. I've lost count of the number of > times I've seen loads of mutually exclusive bools because people didn't plan > ahead. >
Or because people didn't update existing bools to enums when they decided they needed a new mutually existing one. It's not that we don't plan ahead, it's that we often don't update code when the situation or our understanding changes. If we add this as an enum, it will only have two fields. Some time from now, someone unfamiliar with this conversation will look and ask "Why is this an enum? It only has two fields" and then they'll switch it to be a boolean. jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
