Paul Clapham

Sheriff
+ Follow
since Oct 14, 2005
Paul likes ...
Eclipse IDE Firefox Browser MySQL Database
Vancouver, Canada
Cows and Likes
Cows
Total received
43
In last 30 days
0
Total given
83
Likes
Total received
2245
Received in last 30 days
13
Total given
434
Given in last 30 days
5
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Paul Clapham

Sorry, I don't. I have no experience with Synthesizer, I just looked for a relevant tutorial online and found one. I didn't even pause to see if the tutorial came with sample code -- most of Oracle's tutorials do, so maybe this one does as well. Usually what I do when I'm learning a new area of Java which I know nothing about is this: Find a tutorial with sample code, and then tinker with the sample code, changing it until it turns into the code I wanted to write in the first place.
8 hours ago
Notice how the compareTo() method is in the SupplierNotificationListDetail class? So it's a SupplierNotificationListDetail object which is running the code in that method, and it's given another SupplierNotificationListDetail object as its parameter.

If that doesn't ring a bill, you could have a look at the Oracle tutorial: Object Ordering.
11 hours ago
Yes, that's in the tutorial which I linked to, in the section headed "Voices".
11 hours ago

Anuraag Kumar wrote:Am unable to understand the above quote. Please do correct me if am wrong. Suppose if I take String s = "password"; Then if I later change it to s = "Password2", then s will be referring to "Password2" right. Am aware that in this scenario a new object is created and assigned to s. But I was able to change it correct?  Appreciate your kind help for this query.



Looks like you're making the common error of confusing objects and references. A String object is immutable -- there are no methods which can change the state (i.e. the contents) of a String object. However variables are not necessarily immutable -- like in your example, it is possible to change a variable to refer to a different object. But that doesn't change the object, only the variable. (A variable can be made immutable by declaring it "final".)

Programmers will often talk about objects and variables as if they were the same thing, but that's only because it gets tedious to keep saying things like "the variable which refers to the object containing the vendor's name". And once you're used to the distinction between a variable and the object it refers to, that usually isn't a problem.
11 hours ago
As it stands, that code would be correct if your SupplierNotificationListDetail class had implemented Comparable<SupplierNotificationListDetail>, which it really should do. So I'd fix that first. Then carry on with what Norm suggested.
11 hours ago
Have you tried that little test while allocating different amounts of memory to the JVM? I would think that might make a difference. It would also be interesting if it didn't make a difference.
11 hours ago

Utpal Kumar wrote:I could find toString() method overloaded in any collection class or Interface...



You just didn't finish looking. TreeSet doesn't override toString() -- you probably looked there already. Its superclass is AbstractSet, which also doesn't override toString. But the superclass of AbstractSet, which is AbstractCollection -- it does override toString(). And the API docs say:

Oracle wrote:Returns a string representation of this collection. The string representation consists of a list of the collection's elements in the order they are returned by its iterator, enclosed in square brackets ("[]"). Adjacent elements are separated by the characters ", " (comma and space). Elements are converted to strings as by String.valueOf(Object).

12 hours ago

Ioannis Michailidis wrote:The current Polygon class is simply Polygon You are suggesting I should mess with it (how?)



Well, now that I know it's a standard class from the API, I wouldn't suggest messing with it (since you can't). You didn't mention that originally, which therefore made my advice less useful.

So now I don't know what to suggest. But that's mostly because I don't know what you've already done. If the Polygon.contains() method doesn't work for you and you don't have any other code already in place which you're supporting, then maybe write your own Polygon class. But if the only reason you need a version of Polygon is to use the contains() method, then maybe write a contains() method in your own code which works for you.
1 day ago

kennith stomps wrote:Clearly the first and last names aren't single things, "it" was as in return the method. In my code does it look at all as if I am attempting to return a "single thing"? No, not at all, what a nonsense answer.



You don't "return a method". That's just not how Java works. You return a value from a method (unless you declare that it returns "void"). And "a value" is "a single thing". Java doesn't have the ability to return more than one thing. I would have thought you knew that by now, you've been asking questions here for several months.
2 days ago

kennith stomps wrote:I am simply trying to have the concatNames method get the first and last name from the user, and pass it to the main method once it is called.



Your problem is hidden right there in that statement. You said "the first and last name" and then you referred to those things using the pronoun "it". But "it" must refer to a single thing. So what single thing did you want to return? The first and last name aren't a single thing.
2 days ago
I have this part of my brain which works on problems when I've already decided not to work on them. And then this afternoon it popped up and told me what you really meant. Similar to what Piet said, it looks to me like you really need to modify your Polygon class to allow both (real) points and fictitious points.

At least that's one possibility. Your suggestion of having SuperPolygon as that class which can have real and fictitious points, and Polygon as a subclass which can only have real points, that's another possibility. But when one class is a specialized version of its superclass, that can be a design error. For an illustration of what I mean, consider a Rectangle class with width and height attributes. And then consider a specialized subclass of Rectangle called Square, which would somehow force the width and height to be the same. For an explanation of why that's a problem, have a look at A Square Is Not a Rectangle, written by somebody far better than me at object-oriented design.

So that's why I would suggest tearing apart Polygon and making it work with fictitious points. But I don't know a lot about your class design, so there might be reasons why it's not a design error.
2 days ago
Could you be more specific about what's included in the "everything" which you say will have to be evaluated?
2 days ago

Ioannis Michailidis wrote:Well, this point lies in the core of the question. I think that a SuperTriangle with some virtual vertices is a Superclass of a normal triangle and not vice versa. I am afraid if I simply extend Polygon, consequently bad things will happen.



It's fairly easy to figure out whether Polygon is a subclass of SuperTriangle. Ask yourself: "A Polygon IS-A SuperTriangle... true or false?" To me that's false, because presumably a square isn't a SuperTriangle. (I'm assuming these are the ordinary triangles and polygons familiar to Pythagoras and so on.) Now let's try this: "A SuperTriangle IS-A Polygon... true or false?" Well, yeah, obviously. So SuperTriangle is a subclass of Polygon.

Is there no pattern in which a subclass "becomes" a superclass?



Nope.

But I don't understand what these bad things are which you are afraid of. A SuperTriangle is a Polygon, except it behaves differently in some way. You would take care of those differences by overriding methods.

However... if adding SuperTriangle to your data model causes Polygon to not work correctly, then yes, you'll have to fix Polygon in some way to take care of that.
2 days ago

Garrett Boring wrote:Well the final hasn't had a number assigned to it so it's just zero and the string...args should be String[] args, I believe. Hope this helped you out!



Well... no to both of those. The final static variable hasn't had a value assigned to it, so that's an error and the program doesn't compile. As for "String... args", that's called "varargs" in Java and it means the same thing as "String[] args".
2 days ago