Re: this

On 4/28/2012 9:33 PM, mojde wrote:


if you write a class like this:

class Apple { String color = "";
     setColor(String s) { this.color = s }
}

then say you have two apple objects:

Apple a1 = new Apple();
Apple a2 = new Apple();

then when you encounter a statement that says:

a1.setColor("red");

the code for a1.setColor encounters "this.color" which refers to that
object's own color variable.

Why?

Because some people do this:

class Apple { String color = "";
     setColor(String color) { this.color = color }
}

Notice now that "this.color" refers to the object's color variable, and
"color" refers to String color in the scope of the local method.

There are other reasons. You may want a class to store a handle of
itself somewhere else. For example, the following method:

public Apple getInstance() { return this }

The above method returns the particular instance of Apple. In this case,

Apple a1 = new Apple;

Now, the following two statements produce identical results:

Apple a2 = a1;
and
Apple a2 = a1.getInstance();

You can also use this to call alternate constructors.
For example;

Apple () { this("red") }
Apple (String s) ( setColor(s) }

One of the more interesting usages of "this" remains passing a reference
to an object versus defining scope. It can be used to create a way to
pass a function as an argument. For example, if we have a well-known
function name encapsulated as a class (think "Thread", "Runnable", or
"Callable"):

class Callable { callme(Object o) { /* code here */ } }

class Println extends Callable { callme(Object o) { println(o); } }
class Print extends Callable { callme(Object o) { print(o); } }

Now you can instantiate an instance of CallableFunction, and pass it as
an argument.
Println p1 = new Println();
Print p2 = new Print();

String = "whatever"
Callable func = new Print();

processcommand (func, whatever);

The code for process command would be as follows, of course:

processcommand(Callable c, Object o)
{ c.callme(o); }

This has applications all over the place from parsing XML to storing
game tree data for a chess file editor, for example, which would allow
you to traverse back and forth in a tree simply by following the
commands contained in the command-nodes which comprise the tree. The
main use here is in processing large numbers of commands. if you have a
switch statement, for example, containing fifty cases, you might begin
to wonder if this method finds a result faster, since it directly looks
up a reference to the code you need to execute (plus one or two extra
method calls).

So for example if you're writing a fighting video game you can't be slow
and have 100 if's or a switch for determining which move to animate
next; you need to get the move immediately and process it.

Also it helps you contain the code in one place; if you use a switch,
there's no guarantee you won't need another separate switch statement
somewhere else if you need new functionality. Using this method I've
described you can just write a default behavior into a base class.

Like lets say your writing a database which searches through a million
chess games. Say for AI. And you need to traverse a lot of game trees
and rotate positions and stuff like that. You pretty much have to use
the this keyword. So it does have it's uses, but for run of the mill
everyday programming it's safer to just use a simple 5 or 10 case
switch. Or not. Or whatever.