dissecting some simple code in detail
michael
I work with things better if I understand why they are the way they
are. I am going through a Java Tutorial and i'd like to get a better
understanding of what I am doing rather than just knowing what to do.
I'd like to post some lines of code here to see if I am understanding
the anatomy of its syntax correctly.
For example:
Color color = JColorChooser.showDialog(this,"Foreground
Color",jTextArea1.getForeground());
Is a line of code I am using to attach functionality to a menu item
that the tutorial has had me contruct. (the complete function is at
the bottom of this post)
My guess (which may be completely wrong) as to what this line of code
says is the following: (Please correct or elaborate on my guess)
"Color color" declares a variable (private to the current object by
default?) named "color" and says that its type will be of the object
class "Color". The "Color" object class has space in it to store RGB
values or some such color coordinates.
The "=" says that we are not only declaring the variable, but that we
are going to load it with some value that will be generated on the
right side of the equation. Now this raises the question: variables
like color are objects. Objects have many different attributes, such
as name, value, etc... With a phrase like "Color color =" what
criteria does java use to decide which of the attributes of the object
will need to be assigned to the value on the right side of the
equation? Does java automatically know that since Color belongs to the
variable class of objects that there is going to be some number loaded
in it, and if no attribute is named that it should load values into
that attribute by default?
"JColorChooser.showDialog" says that we are going to use this method
of the menu item. This method being ready to receive user input.
"(this,) says that the menu item that we will be calling this function
on is part of the object "this" which I believe is the frame that the
menu item pops off.
I do not know what the "..., "Foreground Color",..." part of the
arguement does. What is the significance of the fact that it is in
quotes?
Finally, the "..., jTextArea1.getForeground())" part of the arguement
gets that actual string that will be loaded into the value of the
color variable. The object jTextArea1 has a foreground color attribute
which we are retrieving. Why though are there empty parentheses after
this attribute?
Code for the menu action:
void jMenuItem6_actionPerformed(ActionEvent e) {
//handle the foreground menu item
Color color = JColorChooser.showDialog(this, "Foreground Color",
jTextArea1.getForeground());
if (color != null)
jTextArea1.setForeground(color);
this.repaint();
}}
Greg Faron
>
> Color color = JColorChooser.showDialog(this,"Foreground
> Color",jTextArea1.getForeground());
>
> Is a line of code I am using to attach functionality to a menu item
> that the tutorial has had me contruct. (the complete function is at
> the bottom of this post)
>
> default?)
The parenthetical statement above is incorrect. [After looking at the
full code below, I found that] The definition takes place within the
confines (or "scope") of a method. Therefore the variable 'color' is
not known to the class which houses the method, but only to the method
body itself. To declare this variable (not "member") as anything such
as private or public would be an error. It's commonly referred to as a
"local variable."
> named "color" and says that its type will be of the object
> class "Color". The "Color" object class has space in it to store RGB
> values or some such color coordinates.
true
> The "=" says that we are not only declaring the variable, but that we
> are going to load it with some value that will be generated on the
> right side of the equation.
true
> Now this raises the question: variables
> like color are objects. Objects have many different attributes, such
> as name, value, etc... With a phrase like "Color color =" what
> criteria does java use to decide which of the attributes of the object
> will need to be assigned to the value on the right side of the
> equation?
None of the "attributes" are assigned. The object as an entire entity
is assigned. If I said that my car is a Dodge Durango, I'm not saying
that it's steering wheel is a Dodge Durango, or that it's gas efficiency
is a Dodge Durango. The car itself is a particular Dodge Durango, which
may or may not have attributes assigned to it (color, engine style,
etc).
> Does java automatically know that since Color belongs to the
> variable class of objects that there is going to be some number loaded
> in it, and if no attribute is named that it should load values into
> that attribute by default?
Look at the java.awt.Color class. You'll notice a finite number of
"constructors." These are methods that have the same name of the class,
and are the only way to construct a new object from scratch. The author
of a given class is responsible for describing what minimal data is
needed for a valid object construction, or what default data is used if
specific information is not provided [in whole or in part].
In the case of the line above, no constructor of the Color class is
explicitly called. Instead, a Color object is returned from the method
that is being called. Using the previous car example, imagine that your
standing in front of a closed garage door. You know if you knock on the
door, it will open and a car will be driven out. You don't know how or
where that car was constructed (Detroit, 20 years ago or the instant you
knocked?), but it's here now. The garage door is symbolic of the method
that returns the Color object, and you knocking on the door represents
the calling of that method.
> "JColorChooser.showDialog" says that we are going to use this method
> of the menu item.
False assumption imbedded above. The method
void jMenuItem6_actionPerformed(ActionEvent);
is not a method of the MenuItem object. It is [assumably] a method of a
catch-all ActionListener implementation; don't the name fool you.
showDialog is definitely not a member method of the MenuItem class
either. JColorChooser is a class in the SWING package. showDialog() is
a "static" method of that class. This particular method has the side
effect of popping up a GUI object that allows the user to select a color
from a palette. I say side effect because some may argue that the
intended purpose of a method is to return a value. However it goes
about doing that is its own business and this one decides to show a
color selection tool onscreen. This is a debatable semantic.
I'll cover the rest of your post here, as too much of it is based on
minor falsehoods. The arguments to showDialog() are [in this order]:
a Component (or derivative) object used to act as a location
basis for the popup,
a title for the popup window, and
an initial color for the palette to display.
The initial color is not a String object, but an actual Color object.
It happens to be the foreground color (in this case, it's synonymous
with the font color) of the text field. It appears that the main
purpose of this handler is that it changes the font color for the text
field. When activated, it pops up a color palette over the text field
initialized with the current color of the text field. When it
disappears, [if a valid selection was made] the text field is updated
with the chosen color.
> Code for the menu action:
>
> void jMenuItem6_actionPerformed(ActionEvent e) {
> //handle the foreground menu item
> Color color = JColorChooser.showDialog(this, "Foreground Color",
> jTextArea1.getForeground());
> if (color != null)
> jTextArea1.setForeground(color);
> this.repaint();
> }}
--
Greg Faron
Integre Technical Publishing Co.
Joe Cosby
feverishly;
thunder crashed, mic...@farheap.com (michael) laughed madly, then
wrote:
>Hi All,
>
>I work with things better if I understand why they are the way they
>are. I am going through a Java Tutorial and i'd like to get a better
>understanding of what I am doing rather than just knowing what to do.
That's a very good approach, in my opinion.
One thing that will help you a lot is to keep the api docs handy while
doing this kind of thing.
The docs for 1.3.1 are here:
http://java.sun.com/j2se/1.3/docs/api/index.html
I don't remember where the download is, but you can search for it on
Sun's site.
That way you can dissect an example by looking up the classes
involved.
>I'd like to post some lines of code here to see if I am understanding
>the anatomy of its syntax correctly.
>
>For example:
>
>Color color = JColorChooser.showDialog(this,"Foreground
>Color",jTextArea1.getForeground());
>
>Is a line of code I am using to attach functionality to a menu item
>that the tutorial has had me contruct. (the complete function is at
>the bottom of this post)
>
>My guess (which may be completely wrong) as to what this line of code
>says is the following: (Please correct or elaborate on my guess)
>
>"Color color" declares a variable (private to the current object by
>default?) named "color" and says that its type will be of the object
>class "Color". The "Color" object class has space in it to store RGB
>values or some such color coordinates.
>
Yes.
Here's the doc for the class 'Color'
http://java.sun.com/j2se/1.3/docs/api/java/awt/Color.html
describing all of the fields (data), constructors and methods
available to you as a programmer.
>The "=" says that we are not only declaring the variable, but that we
>are going to load it with some value that will be generated on the
>right side of the equation. Now this raises the question: variables
>like color are objects. Objects have many different attributes, such
>as name, value, etc... With a phrase like "Color color =" what
>criteria does java use to decide which of the attributes of the object
>will need to be assigned to the value on the right side of the
>equation? Does java automatically know that since Color belongs to the
>variable class of objects that there is going to be some number loaded
>in it, and if no attribute is named that it should load values into
>that attribute by default?
>
In this case, the Color object is being returned by the showDialog
method belonging to the JColorChooser class.
http://java.sun.com/j2se/1.3/docs/api/javax/swing/JColorChooser.html
A lot of your following questions will be answered by examining the
method signature of the method
public static Color showDialog(Component component,
String title,
Color initialColor)
Ignoring the 'static' keyword for now, next you see that the return
value of showDialog is a 'Color' object.
If an attribute isn't set explicitly then it will get a default.
(Although in some cases a 'default value' can be null, so you have to
look at the particular class to know exactly what to expect in a
specific circumstance). You'll never get an 'incomplete object'.
This case is a little unusual for another reason, the showDialog
method is accessed via a static class, JColorChooser
Most often, you create an object first, then call methods of the
created object (like in this example, you've got 'jTextArea', which
was created somewhere else in the program, and you call
'getForeground()' on the created object). In this case though, you
are calling the class itself. You never have to create an instance
like you did with jTextArea, The 'static' keyword indicates a method
which can be accessed directly from the class.
>"JColorChooser.showDialog" says that we are going to use this method
>of the menu item.
It's not a method of the menu item, but of the JColorChooser class.
It is though called from within a method which appears to be a method
of the menu (although the method name "jMenuItem6_actionPerformed" is
weird, I'd have to see the rest of the code).
>This method being ready to receive user input.
The rest of these questions can be answered by looking up the method
showDialog, where they're explained. I think you'll find them more or
less self-explanatory when you read them.
>"(this,) says that the menu item that we will be calling this function
>on is part of the object "this" which I believe is the frame that the
>menu item pops off.
>
>I do not know what the "..., "Foreground Color",..." part of the
>arguement does. What is the significance of the fact that it is in
>quotes?
>
The double quotes make it a string literal. That is, it represents a
string of text characters.
JFileChooser.showDialog( ...
tells the compiler/runtime system to find a static method called
showDialog of a class called JFileChooser and execute it, but
"JFileChooser.showDialog("
would just represent a series of letters, and the compiler and runtime
system won't make any attempt to interpret them or what they mean.
You can print a string out to the console, or in this case it's the
title of the color chooser dialog that comes up (it will be at the top
of the window)
>Finally, the "..., jTextArea1.getForeground())" part of the arguement
>gets that actual string that will be loaded into the value of the
>color variable.
getForeground() won't return a string, but will return another Color
object.
Like with the JFileChooser class, you can look up the JTextArea class
and find the getForeground() method to see what it's return type is.
> The object jTextArea1 has a foreground color attribute
>which we are retrieving. Why though are there empty parentheses after
>this attribute?
>
getForeground() isn't an attribute, but a method. A verb, instead of
a noun.
You rarely access attributes directly, but usually go through a
get...() or set...() method.
--
Joe Cosby
http://joecosby.home.mindspring.com
Caught in New York, beneath the animals of the village, the Piper
pulled down the sky
Sig by Kookie Jar 5.98d http://go.to/generalfrenetics/
Patricia Shanahan
it easier to understand what is really going on.
Try to distinguish between the class of an object and the type of a
variable or expression. See interleaved comments.
michael wrote:
>
> Hi All,
>
> I work with things better if I understand why they are the way they
> are. I am going through a Java Tutorial and i'd like to get a better
> understanding of what I am doing rather than just knowing what to do.
> I'd like to post some lines of code here to see if I am understanding
> the anatomy of its syntax correctly.
>
> For example:
>
> Color color = JColorChooser.showDialog(this,"Foreground
> Color",jTextArea1.getForeground());
>
> Is a line of code I am using to attach functionality to a menu item
> that the tutorial has had me contruct. (the complete function is at
> the bottom of this post)
>
> My guess (which may be completely wrong) as to what this line of code
> says is the following: (Please correct or elaborate on my guess)
>
> "Color color" declares a variable (private to the current object by
> default?) named "color" and says that its type will be of the object
> class "Color". The "Color" object class has space in it to store RGB
> values or some such color coordinates.
"Color color" declares a reference variable "color" which can either be
null, or point to an object of class Color or one of its subclasses. The
variable "color" only needs space to store a pointer, not an object.
>
> The "=" says that we are not only declaring the variable, but that we
> are going to load it with some value that will be generated on the
> right side of the equation. Now this raises the question: variables
> like color are objects. Objects have many different attributes, such
> as name, value, etc... With a phrase like "Color color =" what
> criteria does java use to decide which of the attributes of the object
> will need to be assigned to the value on the right side of the
> equation? Does java automatically know that since Color belongs to the
> variable class of objects that there is going to be some number loaded
> in it, and if no attribute is named that it should load values into
> that attribute by default?
The "=" says that the variable color should be initialized with the
value of its right hand side. The right hand side will be a reference
expression that is either null, or points to an object of class Color or
one of its subclasses. I know that because I checked the API
documentation at http://java.sun.com/j2se/1.3/docs/api/index.html, and
it says that JColorChooser.showDialog returns type Color. The compiler
knows that because it had access to class JColorChooser during the
compilation.
There will be no copying of attributes from one object to another, only
copying of a pointer to an object from a method result to a reference
variable.
>
> "JColorChooser.showDialog" says that we are going to use this method
> of the menu item. This method being ready to receive user input.
> "(this,) says that the menu item that we will be calling this function
> on is part of the object "this" which I believe is the frame that the
> menu item pops off.
>
> I do not know what the "..., "Foreground Color",..." part of the
> arguement does. What is the significance of the fact that it is in
> quotes?
That means it is a String literal. Before getting this detailed on a
particular call, I would suggest getting used to the basic syntax
writing code that does not use complicated graphics interfaces.
>
> Finally, the "..., jTextArea1.getForeground())" part of the arguement
> gets that actual string that will be loaded into the value of the
> color variable. The object jTextArea1 has a foreground color attribute
> which we are retrieving. Why though are there empty parentheses after
> this attribute?
Because it isn't an attribute but a parameterless method call.
michael
clarifying a lot of the subtleties i felt I was missing. One of these
days I'll find the time to take a programming class.
Greg Faron <gfa...@integretechpub.com> wrote in message news:<3B6F18F1...@integretechpub.com>...
michael
> >
> > Color color = JColorChooser.showDialog(this,"Foreground
> > Color",jTextArea1.getForeground());
> >
> > Is a line of code I am using to attach functionality to a menu item
> > that the tutorial has had me contruct. (the complete function is at
> > the bottom of this post)
> >
> > "Color color" declares a variable (private to the current object by
> > default?)
>
> The parenthetical statement above is incorrect. [After looking at the
> full code below, I found that] The definition takes place within the
> confines (or "scope") of a method. Therefore the variable 'color' is
> not known to the class which houses the method, but only to the method
> body itself. To declare this variable (not "member") as anything such
> as private or public would be an error. It's commonly referred to as a
> "local variable."
Can you give me an illustrative analogy or definition that delineates
the differences between public, private, global and local variables?
Greg Faron
>
> Greg wrote:
> > The parenthetical statement above is incorrect. [After
> > looking at the full code below, I found that] The definition
> > takes place within the confines (or "scope") of a method.
> > Therefore the variable 'color' is not known to the class
> > which houses the method, but only to the method body itself.
> > To declare this variable (not "member") as anything such
> > as private or public would be an error. It's commonly
> > referred to as a "local variable."
>
> Can you give me an illustrative analogy or definition that
> delineates the differences between public, private, global
> and local variables?
Let's start with the definition. There are two types of variables
that Java permits: members and local. This is not entirely accurate
across the board, but will serve for the purposes here. A Member is
loosely defined as something that belongs to an object. Members can be
either objects themselves, or primitive data types (or methods for that
matter, but we won't go there now). Local variables may also be either
objects (e.g. Color, String) or primitive data types (e.g. int, double,
char).
Members must have a permission level set to them upon declaration.
There are four permission levels in Java (the definitions of these
levels can be found online and are left as an exercise to the reader).
They are public, protected, private, and package. The last one is not
explicitly typed, but inferred if none of the first three are applied.
Member variables are omnipresent for the life of the object, though
their values may change. They may even be set to 'null' but the
variable itself is still present (See Patricia's comments on pointers);
it's the value of the variable that is no longer there.
Local variables cannot have permissions set to them as they are not
viewable by the [parent?] object. Logically, a permission would have no
valid meaning and is therefore an compilation error when found. Local
variables are constructed, used, and destroyed within the confines of
the immediate [inferred] brace pair ( {...} ). For example, in the
following code block, there are 3 levels of scope. The variable 'a'
persists the longest, because it is in the outermost pair of braces.
Likewise, 'b' persists longer than 'c'.
public void doNothing()
{
int a = 3;
while (true)
{
int b = 2;
if (true)
int c = 1; // Trick statement -- the braces are implied
break;
} // ends while
} // ends doNothing(void)
Let me think about an analogy today; I need to get back to work for
now.
Greg Faron
>
> Let me think about an analogy today;
Going back to the car analogy from my earlier post, we can think of
the car as a single object. The car has many members contained within
it, and these members describe characteristics about the car. Such
members may be the body style (which is probably a complex object itself
with such members as door count, trunk style, sport/non-sport), the
color, the engine (another complex member), and other semi-permanent
qualities.
When we made our earlier method call (knocking on the garage door), I
said that the car was driven out. Who did the driving? That might be a
local variable who popped into existence when the garage door was
opened, drove the car out of the garage, and was destroyed (or garbage
collected). I've known house flies with longer lifespans, but that's
the point. The qualities of the driver are irrelevant after the car is
delivered, so there's no need for the car itself to know anything about
him.
Of course, one may implement the Car class so that it instead contains
four objects: driver, frontPassenger, rearPassengerLeft,
rearPassengerRight. These objects may be null at any given time, or may
temporarily store the object (person) who's driving the car. In this
design, the mechanic who drove the car out might have been temporarily
part of the car object, as he was stored in the "driver" slot. We he
got out, the reference to him was set to null in the car object, but the
mechanic himself went back into the garage. Since some other object
refers to him now (the garage itself, or the timeclock, or his wife), he
cannot be garbage collected, but my car object no longer cares anything
about him.
It's hard to give a good analogy about permissions of members, as it's
really the programmers prerogative. Make private those members that NO
ONE but you should have access to (your PIN number, for example). Make
protected those members that only you and your descendants should have
access to (keys to the house). Make public those members that you think
everyone should be able to access (your phone number). Package level
permissions are a hybrid between private and protected. Your
descendants (subclasses) do not [necessarily] have access to them, but
any other class in the package does.
I may have slightly confused the permission definitions above a little
("protected" may grant access to everybody in the package as well), but
you really should read their descriptions yourself to cement the ideas
in your head.
michael
things, though I don't think you have finished answering my question
yet.
Greg Faron
On what in particular do you have a question? I tried to describe the
difference between local and member variables. And I described a
portion of the difference in permission settings (though I feel that you
should read the precise descriptions of those online as they are too
lengthy for a newsgroup posting.
<http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html>).
Greg