Paul Clapham

Jesse Silverman wrote:I still to this moment don't understand why Java allows you to redeclare abstract methods inherited from Object in your interfaces -- I don't see what this really ever buys you except confusion.

It does save you from having to write a rule to say that's not allowed, I suppose. And another compiler error message. And as for confusion, where would the certification exams be without it?

That restriction was removed in Java 16.

But probably you aren't using Java 16 yet, so the restriction is still there for you. The reason, as always, is that the Java designers chose to do that. Whether you consider that logical or not, I don't know. You would think they had some reason for it.

henry leu wrote:D. A final instance variable whose value is not set when it is declared or in an initialization block should be set by the constructor.

I understand what this is trying to say, but saying "the" constructor tends to imply there's only one constructor. However saying "a" would be wrong because I'm sure there's a rule (which I can't quote accurately) which requires the final variable to be eventually set no matter which constructor was called. As in my example. But another can of worms would be opened if answer D tried to go into the full details, so maybe it's best left as is.

public class Test {  private final int value;  public Test(int input) {    value = input;  }  public Test () {    this(42);  } }

Here's an example of some of the true statements in the question. (Not including B.) You'll see C and D there, but note that the second constructor has a call to "this()" as its first line. Sure, that doesn't call a constructor of the superclass, but the answer and its explanation didn't say that. So it's an example which contradicts A.

Mike Gualeni wrote:The answer says nothing about methods from Object?! I now that the methods from Object doesn't count to be a functional interface but in Panther there are definitely two abstract methods...

I don't know what any of the answers in the book are. But you're right, methods in Object "don't count" as methods of an interface for the purpose of determining whether it can be a functional interface. And explicitly declaring them in the interface doesn't change that. So effectively the toString() method "doesn't count".

I suppose it's not a bad practice. However let's suppose that you later have to change your code to be like this:

if (a > b) {    System.out.println("a > b");    heads += 1; } else {    System.out.println("a <= b");    tails += 1; }

Then your clean-looking structure of ternary operators is broken and has to be rewritten as if-else again. Still, changes happen and sometimes a seemingly small change can require a larger-than-expected reorganization of your code, so I wouldn't fuss about that too much.

1. Not really. When you see "else" you know it has to be associated with the "if" which precedes it structurally. What I mean is, the code between "if" and its associated "else" can contain anything -- including any number of if-clauses which may or may not have else-clauses, and they may in turn have nested code which in turn may contain anything, and so on.

2. Yes. Other languages make you say "then" before the code controlled by "if", so you'd have for example "if (a==0) then bla bla" or "if (a==0) then bla bla else yada yada", which could maybe be easier to read if you've got a lot of nested if's.

3. I wouldn't say that at all. But on the other hand the problem you're trying to address with this discussion isn't a problem at all for me, so I don't need explanations of that type. And it doesn't mean anything to me either. I'll just mention again that between "if" and its associated "else" there can be all kinds of code.

There's really no such "standard" in Java. If your if-statement requires an else-clause, then write one. And if it doesn't require one, then don't write one.

if (a < 0) {  throw new ArithmeticException(); }
There's no need for an else-clause here, for example, and in fact you shouldn't write one.

Now true, you're describing a situation where the if-statement is inside the else-clause of a different if-statement, but there's no reason why that if-statement should be treated any differently than any other if-statement. So that "standard" doesn't apply there either.

As for the curly braces: Yes, even when there's only one statement being delimited by them. Otherwise it's way too easy to add a second statement which you think belongs in the else-clause (let's say) with the statement which is already there, but it doesn't work that way. However for my personal coding I do make an exception: sometimes there's code at the beginning of a method to weed out situations where nothing needs to happen, so I do like this:

if (value > Math.sqrt(2.0)) return;
Note that it's all on one line, so the standard blunder of adding another line below that is unlikely to happen. And it's a return statement too. But if I worked in a place which insisted on the braces around the return statement there, I wouldn't complain about that.

(I thought that bug where <br> tags showed up sometimes had been fixed, but apparently not. If, when posting, you have a check-box which says "Disable HTML in this message" then checking it makes the bug go away.)

Stephan van Hulst wrote:

Paul Clapham wrote:The global-boolean idea is fine

I strongly disagree. Global variables are never fine.

So I went back to the code where I used this solution (quite a few years ago). The boolean variable is a private member of the JPanel class which has a lot of data items. So it's not a "global" variable. It's part of the panel's state ("Are the panel's components being loaded?"), which other code in the panel can react to as necessary.

But could I get rid of it by moving the code which adds listeners so that it runs after the components are loaded, rather than immediately after each of them are created? It turns out, not really. One of the components of the panel is a JList which, when selected from, fills in new values in the other panel. So it's not just an issue when the panel is first instantiated. Maybe I could have that process remove all of the listeners, then fill in the new values, then add all of the listeners back? Maybe...

So what's the big deal about the listeners anyway? The panel has undo/redo built into most of its components, so when the user sets the value of a component, a listener notices that and writes an edit to the undo manager. But when the program sets the value, the resulting change should be ignored by the undo manager. Problem is, the undo manager can't tell whether the user or the program set the value of a component. That may not be Chris's problem but it's the same sort of problem.

And likewise when the user clicks the "Undo" or the "Redo" button, the resulting change to the component shouldn't result in writing a new edit to the undo manager. Therefore there's special code to tell the undo manager "Hey, it's me, that wasn't the user making that change, just ignore it."

So in my case it's the undo/redo feature which made me do that. Would it be better for the various panels which use the undo manager to be able to tell it to stop listening to change reports, and then later to tell it to start listening again? Probably. Instead of code all over the class having to ask whether a panel-loading event or an undo/redo event is happening and behave accordingly, I could just have the code which handles those events advise the undo manager of them. I might look into that.

Zulfi Khan wrote:I have a variable  opr_CntList. It contains two things: opcode strings and their integer count.

Presumably those strings are in some kind of collection, a list or something like that. Storing their count somewhere is unnecessary since it should be the same as the size of the list. That is, if it's the same then it's redundant and if it's not the same then it's wrong.

Chris Crawford wrote:Is there a standard way to prevent Listeners from activating during initialization? I had experienced a similar problem with another program some years ago and solved it by setting up a global boolean that blocked action by Listeners during initialization.

The global-boolean idea is fine, I notice that I have done that in the past. But you could try not adding the Listeners until the component is ready to listen properly, I suppose.

I don't think anything "goes to null". What I think is that "this" refers to different things at different places in that code, and you're assuming that it's always the same.

ArrayList has so many useful features which an array doesn't have. An array, you have to decide in advance how many entries it's going to have, and then you can't change the size. And then all of the entries are initialized to null, which can trip you up if you don't fill the array completely with objects. (I wouldn't use "works well" to describe that.)

Whereas an ArrayList, you can add entries to it and it gets bigger, and you can remove entries from it and it gets smaller. It's so much more flexible that when I'm writing programs I only create an array if I'm going to pass it to some method which requires an array. Which very rarely happens.

And like I said, sometimes you have to have an array. But maybe it was way more convenient to build an ArrayList which contains the data. That's why you need a tool to convert it to an array.

As a beginning programmer you're going to be taught to use arrays, because those are basic things that have been in computer languages for decades now. But when you need to write real programs, you aren't going to use arrays much. It's sort of like how they teach you to ride a bicycle before you can learn to drive a car -- well, no, they don't do that. It's more like you have to use a hand-powered saw before you can be trusted with a power saw, let's say.

Zulfi Khan wrote:please guide me how to create a variable name for 'operation code and their count List.

A good name for an operation code: operationCode. Or if it happens that "opcode" is the standard name for an operation code in this application and everybody says that, then opCode would be satisfactory.

As for "count list"... I don't understand why you use that term, since all that code does is to produce a list which excludes some of the duplicates in the original list. There's no counting necessary, since the "add" method just adds an entry to the end of its list.

I also have to say that "tempStr" is a very strange name for something which comes out of an ArrayList<Object>. It's almost as if the entries in that list are actually String objects but for some reason the list was declared differently. Anyway I would call that variable current and the variable which is supposed to hold the previous value, I'd call that previous. There's no need to specify that they are Strings even if they are, the algorithm doesn't care and neither does the reader.

I looked at what it takes to go from n=1 to n=2 for a start. For n=1 you've got the two tuples [] and [1], and for n=2 you've got the five tuples [], [1], [2], [12], and [21]. You need to take the two tuples for n=1 and strategically put in some 2's to get the five tuples for n=2.

So let's see how that might be done. Let's keep the original two tuples unchanged for a start, that's [] and [1]. Next let's make modified versions by tacking on 2: that's [2] from the first and [12] and [21] from the second. That gives us the five. All righty then!

Does that work going on to n=3, where we need 16 tuples? We start with the original five: [], [1], [2], [12], and [21]. We keep them. Now we're going to make modified versions by tacking on 3: that's [3] from the first, [13] and [31] from the second, [23] and [32] from the third. The fourth gives us [123], [132], and [312], and the fifth gives us [213], [231], and [213]. Did that work? We had five and we needed eleven more... check.

So that's my algorithm. If we have a tuple with k digits, then tacking on the digit for the next level results in k+1 new tuples.