Quick question

[NickName]

Hi,

The following is a "complete set of sample code" from a java tutorial.
I understand how the code works. But question, where was the instance
of textArea1defined? I understand textArea is a subclass from the AWT
package. Secondly, when a method of an external class can be
called/used directly vs. via instantiation? Read somewhere, don't
recall exactly how.

Many thanks.


// I guess the following line is missing
import java.awt.*;

// original code block starts

Vector vector1 = new Vector();
for (int i = 0; i < 10;i++) {
vector1.addElement(new Integer(i)); //addElement accepts object or
//composite types
} //but not primitive types
//enumerate vector1 using nextElement()
Enumeration e = vector1.elements();
textArea1.setText("The elements using Enumeration's nextElement():\n");
while (e.hasMoreElements()) {
textArea1.append(e.nextElement()+ " | ");
}
textArea1.append("\n\n");
//enumerate using the elementAt() method
textArea1.append("The elements using Vector's elementAt():\n");
for (int i = 0; i < vector1.size();i++) {
textArea1.append(vector1.elementAt(i) + " | ");
}
textArea1.append("\n\n");
//enumerate using the toString() method
textArea1.append("Here's the vector as a String:\n");
textArea1.append(vector1.toString());

// original code block ends

 

[Daniel Pitts]

Hi,

The following is a "complete set of sample code" from a java tutorial.
I understand how the code works. But question, where was the instance
of textArea1defined? I understand textArea is a subclass from the AWT
package. Secondly, when a method of an external class can be
called/used directly vs. via instantiation? Read somewhere, don't
recall exactly how.

Many thanks.


// I guess the following line is missing
import java.awt.*;

// original code block starts

Vector vector1 = new Vector();
for (int i = 0; i < 10;i++) {
vector1.addElement(new Integer(i)); //addElement accepts object or
//composite types
} //but not primitive types
//enumerate vector1 using nextElement()
Enumeration e = vector1.elements();
textArea1.setText("The elements using Enumeration's nextElement():\n");
while (e.hasMoreElements()) {
textArea1.append(e.nextElement()+ " | ");
}
textArea1.append("\n\n");
//enumerate using the elementAt() method
textArea1.append("The elements using Vector's elementAt():\n");
for (int i = 0; i < vector1.size();i++) {
textArea1.append(vector1.elementAt(i) + " | ");
}
textArea1.append("\n\n");
//enumerate using the toString() method
textArea1.append("Here's the vector as a String:\n");
textArea1.append(vector1.toString());

// original code block ends

Actually, this is no where NEAR compete.

There isn't a class defined, and there are no methods defined.

You are right to wonder where textArea1 is defined.

 

[Lew]

....

Actually, this is no where NEAR compete.

There isn't a class defined, and there are no methods defined.

You are right to wonder where textArea1 is defined.

How quaint: Vector and Enumeration. I remember those, from back when the JVM
came with a hand-crank to bootstrap it.

I urge you to think of replacing with List (implemented by your favorite
implementing class) and Iterator. At least the latter, if not the former.

- Lew

 

[NickName]

...



How quaint: Vector and Enumeration. I remember those, from back when the JVM
came with a hand-crank to bootstrap it.

I urge you to think of replacing with List (implemented by your favorite
implementing class) and Iterator. At least the latter, if not the former.

- Lew

Ok. I found the List class under AWT package. Now, I'm dumbfounded by
the following simple code that I created and generated the infamous
java.lang.NoSuchMethodError: main
err msg. IDE env: JBuilder 2005. What's wrong really?

TIA.

import java.awt.*;

public class myList {

public void main(String[] args) {

// instantiate a new list
List ls = new List();

// add items to the list
ls.add("D");
ls.add("o");
ls.add("n");
ls.add(" ");
ls.add("L");
ls.add("i");

// now display each item in original (entry) order
int i;
for (i=0; i < ls.getItemCount(); i++) {
System.out.println(ls.getItem(i));
}
}
}

 

[Derek Tandy]

How quaint: Vector and Enumeration. I remember those, from back when the JVM
came with a hand-crank to bootstrap it.

I urge you to think of replacing with List (implemented by your favorite
implementing class) and Iterator. At least the latter, if not the former.

- LewOk. I found the List class under AWT package. Now, I'm dumbfounded by

the following simple code that I created and generated the infamous
java.lang.NoSuchMethodError: main
err msg. IDE env: JBuilder 2005. What's wrong really?

TIA.

import java.awt.*;

public class myList {

public void main(String[] args) {

// instantiate a new list
List ls = new List();

// add items to the list
ls.add("D");
ls.add("o");
ls.add("n");
ls.add(" ");
ls.add("L");
ls.add("i");

// now display each item in original (entry) order
int i;
for (i=0; i < ls.getItemCount(); i++) {
System.out.println(ls.getItem(i));
}



}
}- Hide quoted text -- Show quoted text -- Hide quoted text -- Show quoted text -

Try java.util.List

Also use an Iterator;

Iterator it = ls.iterate();
while(it.hasNext()) {
System.out.println(it.next());
}

 

[Daniel Dyer]

Ok. I found the List class under AWT package. Now, I'm dumbfounded by
the following simple code that I created and generated the infamous
java.lang.NoSuchMethodError: main
err msg. IDE env: JBuilder 2005. What's wrong really?

Lew meant java.util.List.

The error message is because the main method must be declared static.

Dan.

 

[Lew]

Lew meant java.util.List.

The error message is because the main method must be declared static.

Silly me - this is why there are package names. Next time I shall be clearer.

- Lew

 

[NickName]

Lew meant java.util.List.

The error message is because the main method must be declared static.

Dan.

Yeah, I am now using this class. It works great. However, I don't
fully understand conceptually about this particular line
List <String> ls2 = new ArrayList <String> ();
in the following full set of code. Care to shed some light? Thanks.

Thanks.

/* Goal: create a list, populate it and then display its content */

/* code starts */
import java.util.*;

public class myList2 {

public static void main(String[] args) {

/* try new util List class */
// create an instance of List class,
// with type of String,
// make each element of the list as an array?
List <String> ls2 = new ArrayList <String> ();

// populate the ls2 list elements
ls2.add("Don");
//ls2.add(" ");
ls2.add("Li");

// use Iterator
Iterator <String> it = ls2.iterator();

// display the content of the list
while (it.hasNext()) {
String s = it.next();
System.out.println(s);
}

}
}

/* code ends */

P.S. Couldn't post yesterday due to NG unavailability.

 

[Lew]

Yeah, I am now using this class. It works great. However, I don't
fully understand conceptually about this particular line
List <String> ls2 = new ArrayList <String> ();
in the following full set of code. Care to shed some light? Thanks.

List is a supertype of ArrayList, in particular, List is an interface
implemented by ArrayList. You can declare or use any object as if it were one
of its supertypes, but you give up subtype-specific methods if you do so. In
this case, only the basic List interface contract is needed, but you cannot
implement an interface directly. Presumably ArrayList works better for this
program than TreeList or another List implementation.

You could even say
Object foo = new ArrayList<String>();
but then you could only invoke methods on foo that Object knows about. In
other words, you couldn't invoke
foo.add("");

- Lew

 

[NickName]

List is a supertype of ArrayList, in particular, List is an interface
implemented by ArrayList. You can declare or use any object as if it were one
of its supertypes, but you give up subtype-specific methods if you do so. In
this case, only the basic List interface contract is needed, but you cannot
implement an interface directly. Presumably ArrayList works better for this
program than TreeList or another List implementation.

You could even say
Object foo = new ArrayList<String>();
but then you could only invoke methods on foo that Object knows about. In
other words, you couldn't invoke
foo.add("");

- Lew

Thanks for the quick introduction to Interface.

 

[Lew]

Thanks for the quick introduction to Interface.

Once you've got that down, research the concept of "polymorphism". It is
arguably the most significant object-oriented programming trick.

- Lew

 

[John Ersatznom]

Once you've got that down, research the concept of "polymorphism". It is
arguably the most significant object-oriented programming trick.

"Arguably"? Polymorphism is the beating heart of OO. The other major
thing is encapsulation, but that by itself only gets you something
called "object-based".

 

[Chris Uppal]

"Arguably"? Polymorphism is the beating heart of OO. The other major
thing is encapsulation, but that by itself only gets you something
called "object-based".

No more than "arguably" in my opinion. Encapsulation is much more central to
OO than polymorphism -- you could write nicely structured and comprehensible
(in OO terms) programs without polymorphism (though it'd be a pain), the idea
doesn't even make sense without encapsulation.

By "encapsulation", of course, I mean real division of responsibility along
object boundaries, not just the much weaker idea of encapsulation: "don't use
public fields". "Autonomy" might be a better word for the same idea.

-- chris

 

[Ian Wilson]

No more than "arguably" in my opinion. Encapsulation is much more
central to OO than polymorphism

The beating heart of OO has three chambers: inheritance, encapsulation
and polymorphism ... and abstraction - The beating heart of OO has four
chambers: inheritance, encapsulation, polymorphism and abstraction ...
and message-passing - The beating heart of OO has five chambers: ...

*Nobody* expects the beating heart of OO!

Coming soon: Schism in the church of OO - is the message of
encapsulation delivered directly by inheritance or is it modulated by
polymorphism?

 

[John Ersatznom]

The beating heart of OO has three chambers: inheritance, encapsulation
and polymorphism ... and abstraction - The beating heart of OO has four
chambers: inheritance, encapsulation, polymorphism and abstraction ...
and message-passing - The beating heart of OO has five chambers: ...

I consider inheritance and polymorphism (and message-passing) to be
flipsides of one coin myself. Abstraction is what can be especially well
achieved by polymotphism and encapsulation.

But I still consider the presence of encapsulation, alone, to be merely
"object-based". Would you call a C project with separate modules, and
well-defined module boundaries and interfaces, to be "object-oriented"?
Most wouldn't call that "object-anything" although it has encapsulation.

Object oriented ultimately means that your most interesting things,
aside from atomic primitive values, tend to be objects, and that their
types are effectively ADTs rather than concrete. Encapsulation lets you
change the implementation in the next version without breaking the
client code. Encapsulation with polymorphism lets you change the
implementation at runtime or use different ones in different places
simultaneously. Now THAT's power.

(Object-based code in C is quite easy. Just declare a typedef void *foo
and a bunch of functions that accept a foo as their first parameter,
plus at least one factory function that returns a foo, in the header. In
the source code of the module, these methods make and return, or use, a
struct of some kind internally, casting the pointer. Iterators return a
node pointer as a void * and have a foo next(foo) function to advance
the pointer. Wrap the void * in a struct foo, actually, and the compiler
will complain if foo is used in place of bar, getting you back
typesafety after a fashion. If you want to allocate foos on the stack,
of course, the module has to expose a struct definition so client code
can take its size. Or it can have a different, kludgy factory function
pair: one returns the size of a foo without exposing implementation
details and the other accepts a char array and returns a foo using the
same memory -- client code stack allocates an appropriate-sized
structure using the first function to decide size, casts to char *, and
passes to the second function. Of course, this is all really ugly and
probably bug-prone anyway, so you should just use C++ or Java!)

 

[NickName]

I consider inheritance and polymorphism (and message-passing) to be
flipsides of one coin myself. Abstraction is what can be especially well
achieved by polymotphism and encapsulation.

But I still consider the presence of encapsulation, alone, to be merely
"object-based". Would you call a C project with separate modules, and
well-defined module boundaries and interfaces, to be "object-oriented"?
Most wouldn't call that "object-anything" although it has encapsulation.

Object oriented ultimately means that your most interesting things,
aside from atomic primitive values, tend to be objects, and that their
types are effectively ADTs rather than concrete. Encapsulation lets you
change the implementation in the next version without breaking the
client code. Encapsulation with polymorphism lets you change the
implementation at runtime or use different ones in different places
simultaneously. Now THAT's power.

(Object-based code in C is quite easy. Just declare a typedef void *foo
and a bunch of functions that accept a foo as their first parameter,
plus at least one factory function that returns a foo, in the header. In
the source code of the module, these methods make and return, or use, a
struct of some kind internally, casting the pointer. Iterators return a
node pointer as a void * and have a foo next(foo) function to advance
the pointer. Wrap the void * in a struct foo, actually, and the compiler
will complain if foo is used in place of bar, getting you back
typesafety after a fashion. If you want to allocate foos on the stack,
of course, the module has to expose a struct definition so client code
can take its size. Or it can have a different, kludgy factory function
pair: one returns the size of a foo without exposing implementation
details and the other accepts a char array and returns a foo using the
same memory -- client code stack allocates an appropriate-sized
structure using the first function to decide size, casts to char *, and
passes to the second function. Of course, this is all really ugly and
probably bug-prone anyway, so you should just use C++ or Java!)

The discussions are all enlightening to a beginer like me, the only
downside is that I can't allocate much time to learning java in a
faster pace and test out the theory at the moment, have to go slow (not
by choice). Thanks.

 

[Randolf Richardson]

John Ersatznom wrote: [sNip]

"Arguably"? Polymorphism is the beating heart of OO. The other
major thing is encapsulation, but that by itself only gets you
something called "object-based".

No more than "arguably" in my opinion. Encapsulation is much more
central to OO than polymorphism

The beating heart of OO has three chambers: inheritance, encapsulation
and polymorphism ... and abstraction - The beating heart of OO has four
chambers: inheritance, encapsulation, polymorphism and abstraction ...
and message-passing - The beating heart of OO has five chambers: ...

*Nobody* expects the beating heart of OO!

Heheh, that wording reminds me of Steve Ballmer not counting the fifth
word "yeah" in a video where he said "I have four words for this company
.... I, love, this, company yeah!!!"

http://video.google.com/videoplay?docid=-3446931931514285011&q="lumber cartel"

Coming soon: Schism in the church of OO - is the message of
encapsulation delivered directly by inheritance or is it modulated by
polymorphism?

If the Java gods get angry, I'd be worried that objects might come
crashing down to earth!

 

[NickName]

All,

I realized the little piece of (java concept) doc that come with
Jbuilder 2005 is very limited and some examples are not that good.
Will have to dig into a real java book soon ...

Meantime, see if I can get fundamental concepts clearer and clearer.

On topic of Polymorphism

"
Assume that three subclasses (Cow, Dog and Snake) have been created
based on the Animal abstract class, each having their own speak()
method.

public class AnimalReference
{
public static void main(String args[])
Animal ref // set up var for an Animal
Cow aCow = new Cow("Bossy"); // makes specific objects
Dog aDog = new Dog("Rover");
Snake aSnake = new Snake("Earnie");

// now reference each as an Animal
ref = aCow;
ref.speak();
ref = aDog;
ref.speak();
ref = aSnake;
ref.speak();
}

"

I like the above example, can you do better?

TIA.

 

[John Ersatznom]

Heheh, that wording reminds me of Steve Ballmer not counting the
fifth word "yeah" in a video where he said "I have four words for this
company ... I, love, this, company yeah!!!"

http://video.google.com/videoplay?docid=-3446931931514285011&q="lumber cartel"

What do you expect from Microsoft, though, but shoddy stuff riddled with
off-by-one errors? At least on this particular occasion, it wasn't in an
unfenced array iteration-by-pointer that subtly corrupts memory and
eventually causes winword.exe to crash or XP to blue-screen for the
umpteenth time that day ...

 

[John Ersatznom]

All,

I realized the little piece of (java concept) doc that come with
Jbuilder 2005 is very limited and some examples are not that good.
Will have to dig into a real java book soon ...

Book, schmuck. Don't waste the money; use Sun's Java tutorial and only
resort to actually paying for information if it turns out to be
inadequate for your needs.