===============================================================
The '.' operator (revisited), also the 'this' object reference:
===============================================================

. see Account.java
      Bank.java
      UseAccount.java

. How come a dot is not used when we are referring to a field or 
  a method within a class definition?  For example when we refer to
  'balance' in a dynamic method, e.g., getBalance, in Account class
  in Account.java?

. It is required when we access a field or a method outside the
  Account class definition.  For example, when we refer to 
  'balance' within the main of UseAccount class, we would have to
  use jims.balance assuming that balance is declared public.  If
  private, we would do jims.getBalance().  In either case, the
  question is still valid.

. That is confusing, isn't it?

  Well, there actually is an implicit '.' operator within the
  Account class when you refer to 'balance'.  In fact, you can
  replace 'balance' inside a method in Account by 'this.balance'.

  Hm... What is this 'this' then?

  Well, remember that a class definition (e.g., Account.java)
  acts as the blueprint for creating and using objects?  That is, 
  it (Account.java) is just defining what it should look like and
  how it will be used if you ever create an instance of that class.
  So, by the time any of the code in the class is executed, there
  must be an object already created based on that class' definition
  (blueprint).  So, the code will make sense and be useful only when 
  an object is created.  If you created 1,000 objects based on that
  class definition, there are 1,000 objects all using the same code,
  each having its own copy of the definition (that is a good way to
  look at this situation for our understanding).  When you write the
  following in the main of UseAccount:  

        Account jims = new Account(400);

  jims is an object of type Account.  jims, as an instance of Account,
  from then on 'owns' each and every one of the (dynamic) attributes
  and behaviors (methods) defined in that class.  (Static ones are
  shared among all 1,000 objects.)  In fact, jims becomes the 'owner'
  of those definitions.  Each of those 1,000 instances 'owns' a copy
  of the definitions.  Now, each instance owning a copy of the code
  becomes the 'this' object, the current object.  So, jims is
  synonymous with 'this' while it is executing any of the methods
  defined in that class.  While executing the methods inside the class
  definition, jims is referred to as 'this' and it is implicit in the
  code.  (Note that jims is a local variable most likely in the main
  of another class, i.e., UseAccount.  By the time a method is being
  executed inside the Account class, i.e., inside the method, jims has
  no meaning since jims is not a local variable in that method.  But,
  we are actually referring to the fields inside jims object.  We are
  using the 'this' object reference in that method to refer to the
  object referred to by jims in the main of UseAccount.  This 'this'
  object reference is implicitly available for each field and method
  access while the control is inside that method.  Remember I use the
  phrase: "carrying the object reference as 'this' in its pocket"
  when a method is called?)  So, you can explicitly add 'this.' to any
  field or method call that is being used within a method in a class.
  So, the definition of setBalance method in Account.java (repeated
  here:) 

       public void setBalance (int newBal) {
           balance = newBal;
       }
    
  can be rewritten by adding the implicit 'this' object reference
  without changing the meaning of the method as follows:

       public void setBalance (int newBal) {
           this.balance = newBal;
       }

  You might ask, why not use 'jims.' here instead of 'this.'?  Well,
  jims is a name that is not in scope.  It is a variable defined
  somewhere else, e.g., in the main of UseAccount.java, isn't it?
  That object with the name jims in main of UseAccount is being
  referred to as 'this' here in this method.
    
  What if we wrote setBalance this way?

       public void setBalance (int balance) {
           balance = balance;
       }
    
  What would it mean?  Which balance is the balance declared as a 
  field named balance and which balance is the balance declared as a
  parameter named balance in the method?  Because of the scoping
  rules in Java, both balance's in the body of this method refer to
  the closest definition of balance which is the parameter
  definition.  That is, both balance's are referring to the
  parameter balance.

  Then, how do we make it so that the first balance in the body
  refers to the field balance, and the second balance refers to the 
  parameter balance?  That is exactly what we want them to mean,
  isn't it?  We do it by rewriting it this way:

       public void setBalance (int balance) {
           this.balance = balance;
       }

  This way, the first balance is the one 'owned' by 'this' object
  reference, which is the field.  Of course, you can avoid all this
  confusion by carefully choosing distinctive names, but this example
  illustrates many subtle points.