This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin for Android App Development and have Peter Sommerhoff on-line!
See this thread for details.
Win a copy of Kotlin for Android App Development this week in the Kotlin forum!

Winston Gutkowski

+ Follow
since Mar 17, 2011
Winston likes ...
Eclipse IDE Hibernate Ubuntu
35 years of computing, from junior COBOL nerd to sysadmin for Sun...with a lot of DBA and modelling in between. Resistentialist. Beer lover. Fat cyclist. Bridge Player (fanatical, but mediocre). Trivia buff. Collector of oddities. Liberal (in the old-fashioned sense; but still ABC - Anything but Conservative).
Girvan, South Ayrshire, Scotland
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Winston Gutkowski

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!

It was suggested as a list implementation in the 2nd book I ever read about C, back in the late 80's.

As a fun exercise I wrote a forward linked list in Java based on an "anchored" Ring, that requires almost no effort to synchronise.

5 hours ago

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.

Hmmm. AIR, the 'synchronised' methods in Collections are a bit brutal; but if that's what you need, they certainly work without any extra "design".

@M Burke: however, if that's what you want there are two SkipList implementations that might be better, since skiplists tend to be very "concurrency-friendly": ConcurrentSkipListMap and ConcurrentSkipListSet.

I'd also add one other Collection type, familiar to fans of Wagner: A Ring or Cycle - ie, a collection that starts recycling elements after you read the "last" one. While they're usually associated with Lists, it's not a requirement.

22 hours ago

Junilu Lacar wrote:What really matters when you're refactoring is that software is easy to work with.

True. And I was weaned on the "principle of least surprise".

At the end of the day, the difference between a boolean wrapper and a binary enum wrapper is, as you say, probably down to taste.

But I still like Liutauras's idea of an "inquirable value".

1 day ago

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.

I suspect that part of the problem is the limits of language. A "State" could be almost any of the things we've been talking about, and therefore only works in context, which is why Lamp.State works better for me.
I also take your point about intuitive. A Lamp "feels" like an object, yet we've been dealing with it as a value since the only thing that concerns us is whether it's on or off. We haven't been counting "lamps" as such, but the number of ON's.
That said, if we have two lamp variables, 'downstairs' and 'upstairs', it would seem odd them to be '==' simply because they're in the same state.

About the only thing I've worked out so far is that I prefer an enum to a boolean. :-)

1 day ago

Junilu Lacar wrote:

salvin francis wrote:Hmm... I still think it should not be called Lamp

I agree, an enum with ON/OFF values should not be called Lamp.

Why not? Your Lamp class is essentially a boolean with methods that convert its "state" into English.

And if (and for as long as) that's ALL it is, I prefer Liutauras's Lamp enum; although admittedly, I might call it Light or Bulb.

I admit it's unusual, but as long as a Lamp is essentially a value, I think it's the cleanest and most minimal way of defining it.

The only question then is then whether you might ever want to
(a) Add more fields.
(b) Subclass it.
And if you do, I'd say you're changing its definition to something that isn't a value any more.

1 day ago

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...

OK, I see your point. I'm not sure I agree because in three of those cases the name of the value supplies a contextual meaning for which you would otherwise have to provide a method.

However, I will definitely have to mull it over. :-)

2 days ago

Junilu Lacar wrote:My final vote would still go to a boolean lit variable in a Lamp class.

Question: If, instead of ON/OFF this was some object that could be LEFT/RIGHT, or UP/DOWN, or DEMOCRAT/REPUBLICAN, would you feel any differently?

I guess what I'm trying to find out is if there's any scenario in which you'd choose a two-element enum over a boolean? And if so, why?

Fun discussion. :-)

2 days ago

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.

Well on that basis, Liutauras's Lamp enum is the best of all.
It's certainly the most compact, deals only with values, and only requires one method.

It doesn't "feel" right though. But maybe it's just me.

2 days ago

Liutauras Vilda wrote:I don't see the benefit of having inner enum.

Actually, I've thought about your idea a bit more and now I'm not so sure.

Having Lamp as an enum - neat though it looks - makes it a value, which means it can't hold state information. So it would be impossible to subclass it to be, for example, a DimmableLamp - even if that were possible for enums.

So, neat though it looks, I'm sticking with my 2nd post. :-)

2 days ago

Liutauras Vilda wrote:I don't see the benefit of having inner enum. And later at some higher level could be asked whether the lamp is on or off.

Yup. Best one yet. I got blinded by implementation. :-)

2 days ago

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?"

But that presumes that a lamp can only be in two states. What about a dimmable lamp?

Granted, there are several ways of implementing one, even with a base class that uses a boolean but, as I say, I just prefer the flexibility of an enum.

And what's more, Lamp.State has the advantage of being self-documenting. :-)

2 days ago
Actually, I've decided I like Campbell's version best, so:
3 days ago

salvin francis wrote:I am loving how this discussion has turned out. I like junilu's final code.

Me too, but I also like your idea of an enum, because it decouples the implementation from a boolean. So, borrowing a bit from everybody (but mostly Junilu):
3 days ago

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?

Well, if you're learning Java, probably one of the topics in there.

My suggestion: Once you've signed in, go to the Forums page and have a quick browse around.
Then click on the 'JAVA' link in bold, a little way down on the right hand side. That will take you here, which contains just Java forums.

To start with, you're probably best off posting in 'Beginning Java' until you get used to how to ask questions (which isn't as easy at it might seem).
Once you get more experienced, and used to the tags and controls, you can move on to 'Java in General', and then onto specific topic pages, which are always listed on the right hand side.

And BTW, this is an oft-quoted page for anyone who thinks programming is easy. :-)

Hope it helps. And welcome to JavaRanch!

3 days ago