Tim Holloway wrote:Now THERE'S one I haven't heard of in a long time! Actually, I don't know about reading as such, but they're good for implementing FIFO caches. Push one in, the one before it (the oldest one in the ring) pops out. And around they go!
Tim Holloway wrote:You can make any of the Collections classes thread-safe, if I'm not mistaken by adding a qualification to your definition.
Junilu Lacar wrote:What really matters when you're refactoring is that software is easy to work with.
Junilu Lacar wrote:You just say "Is the lamp on or is it off?" That should be what informs your API design to make it more natural and intuitive.
Junilu Lacar wrote:I agree, an enum with ON/OFF values should not be called Lamp.
salvin francis wrote:Hmm... I still think it should not be called Lamp
Junilu Lacar wrote:Absolutely. Those other examples you gave don't translate naturally to true/false. However, ON/OFF, YES/NO, CHECKED/UNCHECKED, SELECTED/UNSELECTED, these translate naturally to true/false...
Junilu Lacar wrote:My final vote would still go to a boolean lit variable in a Lamp class.
Well on that basis, Liutauras's Lamp enum is the best of all.
Junilu Lacar wrote:I would argue that in this case, there is no need for that kind of flexibility. Again, that makes me think that we're on the edge of falling into the speculative design trap.
Liutauras Vilda wrote:I don't see the benefit of having inner enum.
Junilu Lacar wrote:When I talk about a lamp in this context, I'm not going to say "What's the lamp's state, on or off?" but rather simply, "Is the lamp on or off?"
salvin francis wrote:I am loving how this discussion has turned out. I like junilu's final code.
Gary Crawford wrote:That's exactly the feeling. Thanks for chiming in! So everyone, where would I pose a coding question. What thread/topic area?