Jeremy French

Greenhorn
+ Follow
since May 11, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeremy French


This only works because all Strings are compile time constants. If you have Strings that are computed at runtime or read from external resources, it breaks.



I stand corrected.

Interestingly enough, it was HeadFirst Java that introduced me to this misunderstanding. In Appendix B it specifically states that creating a new String in Java that is identical to a previously created String refers the new object reference to the previously-existing String object. Just to be sure I went back and checked to make sure I wasn't misreading it, but it's there in black and white. I know the authors hang around here occasionally. If anyone knows how to get in touch with them, perhaps they would like to know they're distributing misleading or possibly incorrect information.
18 years ago
Ok. Maybe I can expound a little further. But essentially, you hit the nail on the head. Java has a heap, and being aware of it and how it works makes you a better programmer, but you can probably get by in ignorance. When an object (The only things stored on the heap) has no more references to it, it becomes available for GC. In terms of memory, the object still exists, but your code can't get to it. The Garbage collector then waits for either spare processor cycles or an imminent need for memory to deconstruct qualifying objects. As such, we don't need to worry about deconstructors unless there's some other aspect of the object that needs to be left in a particular state (such as db values).
18 years ago
You could create a listener-type structure, assuming you control all the Collection classes - i.e. they are subclasses, not the native ones. Then adding your deleteable object to the collection would at the same time register the Collection object with the deleteable object. Then when you need to delete the object, loop through your registered listeners and request they nullify their reference to you.

At least I think that would work...
18 years ago

Although this doesn't have anything to do with your question, I'd like to point out that you must be VERY carful when comparing Objects, such as Strings. In the code above, I don't think


if (type=="C7")


does what you think. This compares if type is the same String object as the literal "C7". It does NOT compare the contents of the type with the string literal. To compare the contents you should do this:

code:


if ("C7".equals(type))


In fact, when you compare objects, you should usually use the equals() method.

Sorry if I'm breaking the purpose of this particular thread. However, this paradigm shows up often enough that I wanted to help you avoid making the same mistake in the future.



Actually, because of the immutability of Strings and String pool, this does compare the contents of the string. Try it yourself.


but your point is valid toward normal objects, and I'm aware of the difference.
18 years ago
Sorry, Stan. As I said, I'm new to Java, so I didn't fully understand your post. I had to go educate myself on the Decorator pattern to fully understand what you meant. I think you may be right. I have to think through it some more and consider it in the context of the larger application, but you've all given me some good ideas of where to go. Thank you.
18 years ago
One of the single most important features of Java is Compile Once - Run Anywhere. Open source JVMs would kill that.
18 years ago
No.

getBytes() does not return the number of bytes in a string. It sounds like it does. It doesn't. getBytes() returns an array of bytes(not characters), which, may or may not coincide with the same byte as the character if it were represented in ASCII.

All characters in Java are 2 bytes. Absolutely. All the time. Ignore getBytes(). It's just confusing the issue for you. All characters in Java are 2 bytes.
18 years ago
Yes, that's another approach, but it doesn't get me away from the long switch- or in that case, if- statement. It also means I still have to update the Chord class if I want to start basic and add more complex chord types in the future, as opposed to just creating additional classes.

I apologize if I posted in the wrong forum. I assumed this was a simple OO thing that I just wasn't used to. Didn't realize it would actually require thought to answer.
18 years ago
As to your logic, you simply incorrectly assumed the function of getBytes. It doesn't return the number of bytes the string is using, rather it converts the string to something else entirely, which confusingly uses fewer bytes.
18 years ago
The number of bytes will always be 2 * the number of characters.

The relationship between ASCII and Unicode is that Unicode creates a much higher number of possible characters. However, the original numbers still carry over I believe, as such, what was character # 126 in ASCII is now character # 000126. (That's not technically correct, but if you apply the principal to binary notation rather than decimal notation, then my statement becomes true. It just adds zeroes to the front to use up 2 bytes.)
18 years ago
Yes, I believe you're both correct. Merrill, I considered that approach, but I'm not sure how I would then keep track of what subclasses were available to me. For example, say I wanted to choose a random (or by some other algoithm) Chord that contained a "C" (assuming the Chord has a hasNote(char note) method) - How could I iterate through a list of all available subclasses? Would I have to keep an updated list in the consumer that was doing the choosing? Isn't that basically just another long switch statment? That seems to violoate the rule of (i forget what it's called) not creating code that needs to be updated. Not to say that my first solution didn't also violate this rule, but it's what I'm trying to get away from.
[ May 11, 2005: Message edited by: Jeremy French ]
18 years ago
New to Java, though not to programming.

I have a Note (as in musical) class and a Chord class, which consists of 3 or more notes. However there are many types of chords, and a consumer can call the Chord constructor with the String name of the chord - such as "C7", which means the chord starts with C and is a 7th chord. The type will determine what notes are included in the chord.

My first instinct is to put a long if or switch statement in the constructor that populates a Note array and sets the instance variables,

but that feels not very OO. Should I be making a ChordType Class? or should I make a 7thChord class that extends Chord? Or is the way I have it just as good in terms of OOness?
18 years ago