launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Fri, May 4, 2012 at 12:26 AM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
> On Thursday 03 May 2012 15:22:56 Jonathan Lange wrote:
>> > 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.
>
> Updating a bool to an enum is not trivial and requires a database migration,
> potentially of millions of rows.  The path of least resistance at that point
> is to add more bools.
>
>> 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.
>
> I really doubt that.  Especially when you add a comment to explain the
> potential use of the enum.  You comment your code, right? :)
>

Only when I can't figure out some other way to make it clear.

> I really don't understand the reticence to use enums instead of bools, there
> is zero harm in doing so.

Lots of reasons.

It's work I don't need to do that delivers no benefit to anyone real,
only hypothetical future dude.

Launchpad is chock full of work that we've done "just in case we want
to change it in the future" that we haven't used. Some might consider
that an asset. I believe it to be a liability.

Take your example here: suppress NONE, SUBSCRIPTIONS, ALL. That value
range excludes the ability to keep sending emails about subscriptions
while suppressing all non-subscription email. Today, we don't know
what we want to do for those.

e.g. We could add that to the enum, making it NONE, SUBSCRIPTIONS,
NONSUBSCRIPTION, ALL – i.e. a collapsed truth table of two values. If
ever we want to distinguish somehow between different kinds of
non-subscription emails, then we'd have to add another 4 values to the
enum. Clearly, this behaviour would be better expressed as orthogonal
bools.

Of course, we don't know if we want that behaviour. We might want a
behaviour that's better expressed with an enum. In the absence of use
cases, we should do what's simplest.

jml