Problem with Strings & Characters 3

[MissouriTiger]

Hi,

This is my first time parsing strings in Java. As part of my password & username screens, I'm calling the method below to test the input for invalid characters. I'm only allowing numbers, letters, and "_". The compiler is generating multiple errors, but the main problem seems to involve my casting operation (char to Character). I can't see anything wrong with it. I sure would appreciate some help.


public boolean characterScreen(String s)
{
Character c;
for (int i = 0 ; i < s.length() ; i++)
{
c = (Character)(s.charAt(i));
if ((!isLetterOrDigit(c)) && (getNumericValue(c) != 63))
return false;
}
return true;
}

 

[pipk]

Character is a wrapper class, i.e an object and so cannot be used for casts - i believe you can only cast with primitive types. In order to create a Character you will need to either create it when needed using its constructor, or as you have done, create a Character object and then use whatever &quot;Set&quot; method is available within that class.

I do not have the java reference handy at the moment, but the method you need will probably be something like setChaValuer or something like that.

And bear in mind that c is now an object (of type Character) and not a primitive data type, so in order to retrieve the char value of the class you will need to use the charValue() method.

Try something like this (sorry - haven't checked it but it may point you in the right direction.

public boolean characterScreen(String s)
{
Character c = new Character(s.charAt(i));
for (int i = 0 ; i < s.length() ; i++)
{
if ((!isLetterOrDigit(c.charValue())) && (getNumericValue(c.charValue()) != 63))
return false;
}
return true;
}

 

[MissouriTiger]

Thanks for the help, I'll try this, and I'll study the Character clas in more depth. However, I notice that you say &quot;Character is a wrapper class, i.e an object and so cannot be used for casts&quot; and yet in your example you use it to cast just as i did.

Actually, objects in general can be used for casts. For example, you can upcast to a parent class, but you will lose child class functionality. You can downcast to a child class, if the object in fact is of the child type. Why would you do this? It would take too long to explain, and many of the reasons I'm not aware of anyway.

Can you point me to any good reference materials about manipulating strings in Java?

Thanks again,

Greg

 

[wushutwist]

Actually he is not casting to a Character, he is instantiating a new Character from a char. Big difference. You cannot cast a primitive to anything other than another primitive. An object can be cast to any other object but if it is not an instanceof that object than a ClassCastException will be thrown at runtime.

pipk:

// Instantiate new Character from primitive, OK
Character c = new Character(s.charAt(i));

MissouriTiger:

// Trying to cast a primitive to a Character, Compile error
c = (Character)(s.charAt(i));

Wushutwist

 

[MissouriTiger]

I am such an idiot. I obviously wasn't paying attention. Thanks to both of you. I think I'm on the right track now. _______________________________________
Constructed from 100% recycled electrons

 

[pipk]

wushutwist is right.

you can use objects for casting, but i think you can only cast up an inheritance tree??

i.e. you can cast a sub class into an object of its superclass, but not the other way around - is that right? Although i am quoting C++ constraints, i assume it is the same for java.

 

[wushutwist]

You are correct pipk. Wushutwist

 

[pipk]

Theres me repaeting what missouri tiger said earlier - missouritiger you are not the only one to not read posts properly, i do apologise...

as for books on string manipulation - most java books will have this. i use deitel and deitel java-how to program. this has a whole chapter dedicated to the String class.

but in general i just use the java reference on the sun website. it shows all methods and fields for every class, plus explanation (albeit a brief one). good stuff and free of charge.

 

[meadandale]

Guys,

You can definately cast down the inheritance tree but only if the object you are casting, began life as the type of object that you are trying to cast it to.

For Example:

class A {
..
}

class B extends A {
...
}


now you can do

A a = new B();

B b = new (B)a;

but also you can do

B b = new B();

A a = (A)b;

I CAN'T do this however:

A a = new A();

B b = (B)a;

In general, you can't ADD information to an object which is what you are doing when you try to cast a superclass object into a subclass object. But you can change the references that point to that object to modify it's behavior by using different subclass and superclass references to refer to it with. In this case, it is important to make the distinction between the reference, or handle you are using to communicate with an object and the object itself.

Regards,

Charles

The tricky thing is that in both cases the polymorphism works so any calls made to the object get B behavior but in each case you get a different interface to the object.

 

[wushutwist]

You are confusing an object's type with the object's reference type. What you said is correct but my statement is also correct. The tricky part is realizing that an object's actual type has nothing to do with the type of its reference. That being said, an object itself can never be downcasted to a subclass of itself. Wushutwist

 

[meadandale]

I'm not confusing anything. I know exactly what I am talking about. While the 'object' itself cannot be transformed into a subclass of itself, the references to that object can be cast down the inheritance tree if the object began life as an object of the 'type' you are trying to cast its reference to.

But since most people use object/reference interchangeably (incorrectly) I was making my point in these terms. I even mentioned exactly the point you say I 'am (confused)' about in my last paragraph.

 

[MissouriTiger]

Okay, Meadandale, or anybody, what difference does it make whether I use either of the following declarations?

A a = new B();

B a = new B();

How might my choice here affect what I can and cannot do? What are the advantages/disadvantages of each?

For a more specific example, I recently used a HashMap object for the first time. The example I found in a book looked like the following:

Map myMap = new HashMap();

How does that differ from this:

HashMap myMap = new HashMap();

Also, one other quick question...

Once you cast up, don't you lose the functionality of the object until you cast it back down? In other words, you can't call the childs' methods after it has been upcast to parent, can you? I believe this is what meadandale meant by &quot;in each case you get a different interface to the object.&quot;


_______________________________________
Constructed from 100% recycled electrons

 

[LeonTang]

I agree with meadandale. Both casting up and casting down is possible.

MissouriTiger:

The 'Map' class is an interface, not an actual class. Therefore, you can't create an instance of it. So by creating a HashMap object(which implements Map interface), you are then able to 'create' a Map object.

Regards,
Leon If you need additional help, you can email to me at zaoliang@hotmail.com I don't guaranty that I will be able to solve your problems but I will try my best

 

[meadandale]

You are right, missouritiger, that is exactly what I meant. When you cast up, you lose information about the object you are referring to. You can only interact with the object as it is defined through the parent's interface. In a well structured inheritance heirarchy, this isn't usually a problem. This is called 'programming to the interface'. In some cases though, you need to add functionality to a child class but the only way to access that functionality is to downcast the reference so that you have access to the interface that the child class presents. This, unfortunately, means that the user of the child class needs to not only know about the parent class but about the child class as well. In a well designed class heirarchy, this is usually not necessary. This is where the design decisions come in. Do you want to insulate users of your children classes from the details of implementation and expose only the superclass interface or do you want them to know about the subclass interface and thus limit the ability to change the implementation?

<sigh>These are some of the difficulties on OOD and OOP. Deciding how to structure your class relationships to get maximum flexibility as well as maximum functionality. It tenuous balance that we all struggle to get right.

Regards,

Charles