Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T17:02:36Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.

The Command pattern solves this problem: A program needs to issue requests to objects. The code that is doing the requesting doesn’t know what the receiver will be, or what operation will be requested.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation
[http://en.wikipedia.or/wiki/Dynamic_programming_language]. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages[http://en.wikipedia.org/wiki/Dynamic_programming_language]:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations[http://www.patterndepot.com/put/8/command.pdf].
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
In C++ and C#, they use the "pointer to methods" to implement command pattern. This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Command Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===
Similar to C#, C++ uses "pointers to methods" to implement command patter.

#include <iostream> #include <string> using namespace std;
class Person;
class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};
class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');
$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');
writeln('END TESTING COMMAND PATTERN');
// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}
function writeln($line_in) {
echo $line_in." ";
}
?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''
Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage
^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !
!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!
flipDown
flipDownCommand perform.!
flipUp
flipUpCommand perform.! !
!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!
turnOn
Transcript show: 'The light is on'; cr.! !
!PressSwitch class methods !
switch: state
" This is the test method
| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.
switch := Switch upMessage: switchUp downMessge: switchDown.
state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ]
Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*Dynamic languages, such as ruby, can change their behavior conveniently at run time, such as reflection and metaprogramming. Therefore, the implementation of command pattern in dynamic languages is much easier and more convenient than that in static language.
*Command pattern is to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Although most actions of static language have to be performed at compile time, static languages have their own solutions to implement command pattern. For example, C and C# use "pointers to methods". Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T16:55:01Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation
[http://en.wikipedia.or/wiki/Dynamic_programming_language]. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages[http://en.wikipedia.org/wiki/Dynamic_programming_language]:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations[http://www.patterndepot.com/put/8/command.pdf].
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
In C++ and C#, they use the "pointer to methods" to implement command pattern. This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Command Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===
Similar to C#, C++ uses "pointers to methods" to implement command patter.

#include <iostream> #include <string> using namespace std;
class Person;
class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};
class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');
$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');
writeln('END TESTING COMMAND PATTERN');
// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}
function writeln($line_in) {
echo $line_in." ";
}
?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''
Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage
^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !
!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!
flipDown
flipDownCommand perform.!
flipUp
flipUpCommand perform.! !
!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!
turnOn
Transcript show: 'The light is on'; cr.! !
!PressSwitch class methods !
switch: state
" This is the test method
| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.
switch := Switch upMessage: switchUp downMessge: switchDown.
state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ]
Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*Dynamic languages, such as ruby, can change their behavior conveniently at run time, such as reflection and metaprogramming. Therefore, the implementation of command pattern in dynamic languages is much easier and more convenient than that in static language.
*Command pattern is to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Although most actions of static language have to be performed at compile time, static languages have their own solutions to implement command pattern. For example, C and C# use "pointers to methods". Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T16:52:37Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation[http://en.wikipedia.org/wiki/Dynamic_programming_language
]. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages[http://en.wikipedia.org/wiki/Dynamic_programming_language
]:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations[http://www.patterndepot.com/put/8/command.pdf].
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
In C++ and C#, they use the "pointer to methods" to implement command pattern. This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Command Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===
Similar to C#, C++ uses "pointers to methods" to implement command patter.

#include <iostream> #include <string> using namespace std;
class Person;
class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};
class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');
$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');
writeln('END TESTING COMMAND PATTERN');
// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}
function writeln($line_in) {
echo $line_in." ";
}
?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''
Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage
^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !
!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!
flipDown
flipDownCommand perform.!
flipUp
flipUpCommand perform.! !
!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!
turnOn
Transcript show: 'The light is on'; cr.! !
!PressSwitch class methods !
switch: state
" This is the test method
| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.
switch := Switch upMessage: switchUp downMessge: switchDown.
state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ]
Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*Dynamic languages, such as ruby, can change their behavior conveniently at run time, such as reflection and metaprogramming. Therefore, the implementation of command pattern in dynamic languages is much easier and more convenient than that in static language.
*Command pattern is to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Although most actions of static language have to be performed at compile time, static languages have their own solutions to implement command pattern. For example, C and C# use "pointers to methods". Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T16:46:40Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
In C++ and C#, they use the "pointer to methods" to implement command pattern. This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Command Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===
Similar to C#, C++ uses "pointers to methods" to implement command patter.

#include <iostream> #include <string> using namespace std;
class Person;
class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};
class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');
$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');
$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');
writeln('END TESTING COMMAND PATTERN');
// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}
function writeln($line_in) {
echo $line_in." ";
}
?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''
Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage
^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !
!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!
flipDown
flipDownCommand perform.!
flipUp
flipUpCommand perform.! !
!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!
turnOn
Transcript show: 'The light is on'; cr.! !
!PressSwitch class methods !
switch: state
" This is the test method
| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.
switch := Switch upMessage: switchUp downMessge: switchDown.
state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ]
Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*Dynamic languages, such as ruby, can change their behavior conveniently at run time, such as reflection and metaprogramming. Therefore, the implementation of command pattern in dynamic languages is much easier and more convenient than that in static language.
*Command pattern is to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Although most actions of static language have to be performed at compile time, static languages have their own solutions to implement command pattern. For example, C and C# use "pointers to methods". Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T16:38:41Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>

/// MainApp startup class for Structural

/// Command Design Pattern.

/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===

#include <iostream> #include <string> using namespace std;
class Person;

class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};

class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');

$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');

writeln('END TESTING COMMAND PATTERN');

// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}

function writeln($line_in) {
echo $line_in." ";
}

?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''

Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage

^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !

!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!

flipDown
flipDownCommand perform.!

flipUp
flipUpCommand perform.! !

!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!

turnOn
Transcript show: 'The light is on'; cr.! !

!PressSwitch class methods !
switch: state
" This is the test method "

| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.

switch := Switch upMessage: switchUp downMessge: switchDown.

state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ].

Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*Dynamic languages, such as ruby, can change their behavior conveniently at run time, such as reflection and metaprogramming. Therefore, the implementation of command pattern in dynamic languages is much easier and more convenient than that in static language.
*Command pattern is to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Although most actions of static language have to be performed at compile time, static languages have their own solutions to implement command pattern. For example, C and C# use "pointers to methods". Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-31T16:25:14Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>

/// MainApp startup class for Structural

/// Command Design Pattern.

/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===

#include <iostream> #include <string> using namespace std;
class Person;

class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};

class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');

$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');

writeln('END TESTING COMMAND PATTERN');

// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}

function writeln($line_in) {
echo $line_in." ";
}

?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''

Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage

^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !

!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!

flipDown
flipDownCommand perform.!

flipUp
flipUpCommand perform.! !

!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!

turnOn
Transcript show: 'The light is on'; cr.! !

!PressSwitch class methods !
switch: state
" This is the test method "

| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.

switch := Switch upMessage: switchUp downMessge: switchDown.

state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ].

Transcript show: 'Argument #on or #off is required.'.

=Comparison: static vs dynamic=
Based on the above-mentioned examples, we present a short summary on comparison of command pattern in static language (such as Java) and dynamic language (such as ruby).
*

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

File:Command.png

2010-10-22T02:29:38Z

Paullei:

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-22T02:29:14Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>

/// MainApp startup class for Structural

/// Command Design Pattern.

/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===

#include <iostream> #include <string> using namespace std;
class Person;

class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};

class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');

$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');

writeln('END TESTING COMMAND PATTERN');

// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}

function writeln($line_in) {
echo $line_in." ";
}

?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''

Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage

^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !

!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!

flipDown
flipDownCommand perform.!

flipUp
flipUpCommand perform.! !

!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!

turnOn
Transcript show: 'The light is on'; cr.! !

!PressSwitch class methods !
switch: state
" This is the test method "

| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.

switch := Switch upMessage: switchUp downMessge: switchDown.

state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ].

Transcript show: 'Argument #on or #off is required.'.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-22T02:27:36Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example
using System;
namespace DoFactory.GangOfFour.Command.Structural
{
/// <summary>

/// MainApp startup class for Structural

/// Command Design Pattern.

/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
static void Main()
{
// Create receiver, command, and invoker
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker()
// Set and execute command
invoker.SetCommand(command);
invoker.ExecuteCommand();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Command' abstract class
/// </summary>
abstract class Command
{
protected Receiver receiver;
// Constructor
public Command(Receiver receiver)
{
this.receiver = receiver;
}
public abstract void Execute();
}
/// <summary>
/// The 'ConcreteCommand' class
/// </summary>
class ConcreteCommand : Command
{
// Constructor
public ConcreteCommand(Receiver receiver) :
base(receiver)
{
}
public override void Execute()
{
receiver.Action();
}
}
/// <summary>
/// The 'Receiver' class
/// </summary>
class Receiver
{
public void Action()
{
Console.WriteLine("Called Receiver.Action()");
}
}
/// <summary>
/// The 'Invoker' class
/// </summary>
class Invoker
{
private Command _command
public void SetCommand(Command command)
{
this._command = command;
}
public void ExecuteCommand()
{
_command.Execute();
}
}
}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;
public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===

#include <iostream> #include <string> using namespace std;
class Person;

class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};

class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');

$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');

writeln('END TESTING COMMAND PATTERN');

// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}

function writeln($line_in) {
echo $line_in." ";
}

?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''

Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage

^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !

!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!

flipDown
flipDownCommand perform.!

flipUp
flipUpCommand perform.! !

!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!

turnOn
Transcript show: 'The light is on'; cr.! !

!PressSwitch class methods !
switch: state
" This is the test method "

| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.

switch := Switch upMessage: switchUp downMessge: switchDown.

state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ].

Transcript show: 'Argument #on or #off is required.'.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-22T02:23:46Z

Paullei:

Topic: The Command pattern in static and dynamic languages
= Fundamentals =
== What is Command Pattern ?==
In object-oriented programming, the command pattern is a [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] in which an object is used to represent and encapsulate all the information needed to call a method at a later time[http://en.wikipedia.org/wiki/Command_pattern].
This information includes the method name, the object that owns the method and values for the method parameters. Client, invoker and receiver are always associated with the command pattern. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.
Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.
== What are static and dynamic languages? ==
Dynamic programming language is used to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages, which are usually called static language for convenience, might perform during compilation. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them. Most dynamic languages are dynamically typed, but not all.

Actually, the notion of dynamic language is ambiguous sometime because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language. Particularly, the following are generally considered dynamic languages:
* Ruby
* Javascript
* Perl
* PHP
* Smalltalk
= Uses of Command Pattern =
Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations. It is useful for implementing.
== Structure ==
===Terminology ===
We first introduce some terminology terms used to describe command pattern implementations.
* Client: the button, toolbar button, or menu item clicked, the shortcut key pressed by the user.
* Command: declares an interface for executing an operation;
* Execute: It may refer to running the code identified by the command object's execute method.
* Receiver: The actual work to be done by the command.
* ConcreteCommand: extends the Command interface, implementing the Execute method by invoking the corresponding operations on Receiver. It defines a link between the Receiver and the action.
* Invoker: It decides when the method should be called. It takes in the request and calls the receiver by passing the command to it and asks it to carry out the request.
* Concretecommand:
=== Illustration ===
We will use the following graph to illustrate the structure of Command Pattern.
[[Image:Command.png]]
== Why Command Pattern?==
“An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”. This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth.
The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations.
== Advantages and Disadvantages of Using Command Pattern ==
Now that we have understood how the pattern works, it's time to take a look at its advantages and disadvantages.
=== The intelligence of a command ===
* The command is just a link between the receiver and the actions that carry out the request.
* The command implements everything itself, without sending anything to the receiver.
We must always keep in mind the fact that the receiver is the one who knows how to perform the operations needed, the purpose of the command being to help the client to delegate its request quickly and to make sure the command ends up where it should.
=== Advantages of Command Pattern ===
The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that know how to perform it.
* It provides encapsulation of application logic so that it can be executed at a different point of time.

* It allows to execute the application in separate contexts, such as in a different thread or using a different state by separating the application logic and context.

* The separation between application logic and context allows to easier exchange the application logic.
=== Disadvantages of Command Pattern ===
The main benefits of the Command Pattern are discussed above. The major disadvantage of the pattern is that it results in lots of little Command classes that can clutter up a design. However, the routing information that Command objects encapsulate has to go somewhere. If this information is not contained in Command objects, then it will have to go into the Controller. The resulting bloat may necessitate partitioning the Controller into a subsystem, and it will certainly make the Controller harder to understand and maintain.

= Command pattern in static and dynamic languages =
In this section, we demonstrate the implementation of command pattern in both dynamic and static languages by some examples.
== Command pattern in static languages ==
We consider in this article some typical static languages C#, java and C++.
===C#===
This structural code demonstrates the Command pattern which stores requests as objects allowing clients to execute or playback the requests.

// Command pattern -- Structural example

using System;

namespace DoFactory.GangOfFour.Command.Structural

{

/// <summary>

/// MainApp startup class for Structural

/// Command Design Pattern.

/// </summary>

class MainApp

{

/// <summary>

/// Entry point into console application.

/// </summary>

static void Main()

{

// Create receiver, command, and invoker

Receiver receiver = new Receiver();

Command command = new ConcreteCommand(receiver);

Invoker invoker = new Invoker();

// Set and execute command

invoker.SetCommand(command);

invoker.ExecuteCommand();

// Wait for user

Console.ReadKey();

}

}

/// <summary>

/// The 'Command' abstract class

/// </summary>

abstract class Command

{

protected Receiver receiver;

// Constructor

public Command(Receiver receiver)

{

this.receiver = receiver;

}

public abstract void Execute();

}

/// <summary>

/// The 'ConcreteCommand' class

/// </summary>

class ConcreteCommand : Command

{

// Constructor

public ConcreteCommand(Receiver receiver) :

base(receiver)

{

}

public override void Execute()

{

receiver.Action();

}

}

/// <summary>

/// The 'Receiver' class

/// </summary>

class Receiver

{

public void Action()

{

Console.WriteLine("Called Receiver.Action()");

}

}

/// <summary>

/// The 'Invoker' class

/// </summary>

class Invoker

{

private Command _command;

public void SetCommand(Command command)

{

this._command = command;

}

public void ExecuteCommand()

{

_command.Execute();

}

}

}

=== Java ===
Sometimes it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.” The Command design pattern suggests encapsulating (“wrapping”) in an object all (or some) of the following: an object, a method name, and some arguments. Java does not support “pointers to methods”, but its reflection capability will do nicely. The “command” is a black box to the “client”. All the client does is call “execute()” on the opaque object.

import java.lang.reflect.*;

public class CommandReflect {
private int state;
public CommandReflect( int in ) {
state = in;
}
public int addOne( Integer one ) {
return state + one.intValue();
}
public int addTwo( Integer one, Integer two ) {
return state + one.intValue() + two.intValue();
}

static public class Command {
private Object receiver; // the "encapsulated" object
private Method action; // the "pre-registered" request
private Object[] args; // the "pre-registered" arg list
public Command( Object obj, String methodName, Object[] arguments ) {
receiver = obj;
args = arguments;
Class cls = obj.getClass(); // get the object's "Class"
Class[] argTypes = new Class[args.length];
for (int i=0; i < args.length; i++) // get the "Class" for each
argTypes[i] = args[i].getClass(); // supplied argument
// get the "Method" data structure with the correct name and signature
try { action = cls.getMethod( methodName, argTypes ); }
catch( NoSuchMethodException e ) { System.out.println( e ); }
}
public Object execute() {
// in C++, you do something like --- return receiver->action( args );
try { return action.invoke( receiver, args ); }
catch( IllegalAccessException e ) { System.out.println( e ); }
catch( InvocationTargetException e ) { System.out.println( e ); }
return null;
} }

public static void main( String[] args ) {
CommandReflect[] objs = { new CommandReflect(1), new CommandReflect(2) };
System.out.print( "Normal call results: " );
System.out.print( objs[0].addOne( new Integer(3) ) + " " );
System.out.print( objs[1].addTwo( new Integer(4),
new Integer(5) ) + " " );
Command[] cmds = {
new Command( objs[0], "addOne", new Integer[] { new Integer(3) } ),
new Command( objs[1], "addTwo", new Integer[] { new Integer(4),
new Integer(5) } ) };
System.out.print( "\nReflection results: " );
for (int i=0; i < cmds.length; i++)
System.out.print( cmds[i].execute() + " " );
System.out.println();
} }

=== C++ ===

#include <iostream> #include <string> using namespace std;
class Person;

class Command
{
// 1. Create a class that encapsulates an object and a member function
// a pointer to a member function (the attribute's name is "method")
Person *object; //
void(Person:: *method)();
public:
Command(Person *obj = 0, void(Person:: *meth)() = 0)
{
object = obj; // the argument's name is "meth"
method = meth;
}
void execute()
{
(object-> *method)(); // invoke the method on the object
}
};

class Person
{
string name;

// cmd is a "black box", it is a method invocation
// promoted to "full object status"
Command cmd;
public:
Person(string n, Command c): cmd(c)
{
name = n;
}
void talk()
{
// "this" is the sender, cmd has the receiver
cout << name << " is talking" << endl;
cmd.execute(); // ask the "black box" to callback the receiver
}
void passOn()
{
cout << name << " is passing on" << endl;

// 4. When the sender is ready to callback to the receiver,
// it calls execute()
cmd.execute();
}
void gossip()
{
cout << name << " is gossiping" << endl;
cmd.execute();
}
void listen()
{
cout << name << " is listening" << endl;
}
};

int main()
{
// Fred will "execute" Barney which will result in a call to passOn()
// Barney will "execute" Betty which will result in a call to gossip()
// Betty will "execute" Wilma which will result in a call to listen()
Person wilma("Wilma", Command());
// 2. Instantiate an object for each "callback"
// 3. Pass each object to its future "sender"
Person betty("Betty", Command(&wilma, &Person::listen));
Person barney("Barney", Command(&betty, &Person::gossip));
Person fred("Fred", Command(&barney, &Person::passOn));
fred.talk();
}

== Command pattern in dynamic languages ==
In terms of dynamic languages, we consider PHP and Smalltalk.

=== PHP ===
In this example, a BookStarsOnCommand object is instantiated with an instance of the BookComandee class. The BookStarsOnCommand object will call that BookComandee object’s bookStarsOn() function when it’s execute() function is called.

<?php

class BookCommandee {
private $author;
private $title;
function __construct($title_in, $author_in) {
$this->setAuthor($author_in);
$this->setTitle($title_in);
}
function getAuthor() {
return $this->author;
}
function setAuthor($author_in) {
$this->author = $author_in;
}
function getTitle() {
return $this->title;
}
function setTitle($title_in) {
$this->title = $title_in;
}
function setStarsOn() {
$this->setAuthor(Str_replace(' ','*',$this->getAuthor()));
$this->setTitle(Str_replace(' ','*',$this->getTitle()));
}
function setStarsOff() {
$this->setAuthor(Str_replace('*',' ',$this->getAuthor()));
$this->setTitle(Str_replace('*',' ',$this->getTitle()));
}
function getAuthorAndTitle() {
return $this->getTitle().' by '.$this->getAuthor();
}
}

abstract class BookCommand {
protected $bookCommandee;
function __construct($bookCommandee_in) {
$this->bookCommandee = $bookCommandee_in;
}
abstract function execute();
}

class BookStarsOnCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOn();
}
}

class BookStarsOffCommand extends BookCommand {
function execute() {
$this->bookCommandee->setStarsOff();
}
}

writeln('BEGIN TESTING COMMAND PATTERN');
writeln('');

$book = new BookCommandee('Design Patterns', 'Gamma, Helm, Johnson, and Vlissides');
writeln('book after creation: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOn = new BookStarsOnCommand($book);
callCommand($starsOn);
writeln('book after stars on: ');
writeln($book->getAuthorAndTitle());
writeln('');

$starsOff = new BookStarsOffCommand($book);
callCommand($starsOff);
writeln('book after stars off: ');
writeln($book->getAuthorAndTitle());
writeln('');

writeln('END TESTING COMMAND PATTERN');

// the callCommand function demonstrates that a specified
// function in BookCommandee can be executed with only
// an instance of BookCommand.
function callCommand(BookCommand $bookCommand_in) {
$bookCommand_in->execute();
}

function writeln($line_in) {
echo $line_in." ";
}

?>

== Smalltalk ==
In this example we configure the Switch with 2 commands: to turn the light on and to turn the light off.

Object subclass: #Switch
instanceVariableNames:
' flipUpCommand flipDownCommand '
classVariableNames: ''
poolDictionaries: ''

Object subclass: #Light
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

Object subclass: #PressSwitch
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''

!Switch class methods !
upMessage: flipUpMessage downMessge: flipDownMessage

^self new upMessage: flipUpMessage downMessge: flipDownMessage; yourself.! !

!Switch methods !
upMessage: flipUpMessage downMessge: flipDownMessage
flipUpCommand := flipUpMessage.
flipDownCommand := flipDownMessage.!

flipDown
flipDownCommand perform.!

flipUp
flipUpCommand perform.! !

!Light methods !
turnOff
Transcript show: 'The light is off'; cr.!

turnOn
Transcript show: 'The light is on'; cr.! !

!PressSwitch class methods !
switch: state
" This is the test method "

| lamp switchUp switchDown switch |
lamp := Light new.
switchUp := Message receiver: lamp selector: #turnOn.
switchDown := Message receiver: lamp selector: #turnOff.

switch := Switch upMessage: switchUp downMessge: switchDown.

state = #on ifTrue: [ ^switch flipUp ].
state = #off ifTrue: [ ^switch flipDown ].

Transcript show: 'Argument #on or #off is required.'.

= Summary =
In this article we took a quick look at the Command Pattern in static and dynamic languages. Command pattern is a great pattern for disconnecting the command originator and the system receiving the commands. This should be one of the first patterns you consider when thinking about creating a distributed type of system.

Furthermore, the comparison between command pattern in static languages and dynamic languages is actually the comparison between the static languages and dynamic languages. That is, in dynamic language, we can implement command pattern at runtime.
= References =
[[#References|[1]]] Wikipedia - Command_Pattern. [Online].
http://en.wikipedia.org/wiki/Command_pattern

[[#References|[2]]] Command Design Pattern. [Online].
http://sourcemaking.com/design_patterns/command

[[#References|[3]]] Wikipedia - Dynamic programming language. [Online].
http://en.wikipedia.org/wiki/Dynamic_programming_language

[[#References|[4]]] Wikipedia - Design Pattern. [Online].
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

[[#References|[5]]] http://www.patterndepot.com/put/8/command.pdf

[[#References|[6]]] Erich,G., Richard,H., Ralph,J.,and John,M.V. 1997. Design Patterns: Elements of Reusable Object-Oriented Software

[[#References|[7]]] Freeman,E., Robson,E., Bates,B.,and Sierra,K. 2004. Head First Design Patterns

CSC/ECE 517 Fall 2010/ch4 4f ls

2010-10-22T01:04:10Z

Paullei:

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-14T02:43:28Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

== Definition ==
=== What is The Type System? ===
A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.
=== Classification of Type Checking ===
The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.
===Mixing Static and Dynamic Typing ===
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Fundamentals ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

=== Static Typing and Dynamic Typing versus Strong Typing and Weak Typing ===
Static and dynamic typing, and strong and weak typing, are two totally different concepts, which, unfortunately, are very often confused. It is erroneous to say that a language that is static or dynamic typed cannot be strong or weak typed. Static and dynamic typing, and strong and weak typing, are different forms of classification of programming languages, and one of each class necessarily characterizes a given language. It is thus imperative to discuss strong and weak typing vis-a-vis static and dynamic typing.

Programming languages that exhibit "strong typing" are "strong typed," and those that exhibit "weak typing" are "weak typed".

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]].

== Examples ==
=== Is Dynamic Typing Good? ===
In a dynamic typed language, you don't have to initialize variables, which is a big bonus for many developers. Programmers like the fact that you can use a variable at will when required (without having to initialize it). Dynamic typing is characteristic of many of the scripting languages: Perl, PHP, Python, etc. Dynamic typing, in fact, does save you from writing a few "extra" lines of code, which, in turn, means less time spent writing code.

The very characteristic of dynamic typed languages that appeals to many developers is also a pitfall, and a major one at that. Consider the following simple example:

/* Python code */
my_variable = 10
while my_variable > 0:
i = foo(my_variable)
if i < 100:
my_variable++
else
my_varaible = (my_variable + i) / 10 // spelling error intentional

As you can see in the above code, my_varaible is a spelling mistake that the programmer could have very well made. The problem here is that, since Python is dynamically typed, it will not return an error, but instead will create a new variable called my_varaible. So, now we have two variables: my_variable and my_varaible. This obviously is a serious problem; some would suggest that forced variable declaration is an important requirement in any programming language.

=== Static Typed Behavior in Dynamic Typed Languages ===
Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. Consider the following Perl example:

/* Perl code */
$sum = 10;
print $sum;

The above code will run without any problem, and will print 10 to the console. Note that here, we have not initialized the variable sum; this exemplifies the dynamic typing characteristic of Perl. To enforce variable declaration, we make use of the strict pragma as follows:

/* Perl code */

use strict;
$sum = 10;
print $sum;

The above code fragment will return the following error when you try to run it:

Global symbol "$num" requires explicit package name at perl.pl line 2.
Execution of perl.pl aborted due to compilation errors.

To rectify the above error, we are forced to declare the variable num as follows:

/* Perl code */

use strict;
my $num; // forced declaration
$sum = 10;
print $sum;

The above codes are specific to Perl; not all programming languages have a way to enforce variable declaration: Python, for example doesn't have a way to enforce variable declaration. However, there is a tool, called "pychecker" (available here), that can be used to "detect" stray variables; this is, of course, far from a desirable solution.

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-14T02:42:00Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

== Definition ==
=== What is The Type System? ===
A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.
=== Classification of Type Checking ===
The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.
===Mixing Static and Dynamic Typing ===
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Fundamentals ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

=== Static Typing and Dynamic Typing versus Strong Typing and Weak Typing ===
Static and dynamic typing, and strong and weak typing, are two totally different concepts, which, unfortunately, are very often confused. It is erroneous to say that a language that is static or dynamic typed cannot be strong or weak typed. Static and dynamic typing, and strong and weak typing, are different forms of classification of programming languages, and one of each class necessarily characterizes a given language. It is thus imperative to discuss strong and weak typing vis-a-vis static and dynamic typing.

Programming languages that exhibit "strong typing" are "strong typed," and those that exhibit "weak typing" are "weak typed".

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]].

== Examples ==
=== Is Dynamic Typing Good? ===
In a dynamic typed language, you don't have to initialize variables, which is a big bonus for many developers. Programmers like the fact that you can use a variable at will when required (without having to initialize it). Dynamic typing is characteristic of many of the scripting languages: Perl, PHP, Python, etc. Dynamic typing, in fact, does save you from writing a few "extra" lines of code, which, in turn, means less time spent writing code.

The very characteristic of dynamic typed languages that appeals to many developers is also a pitfall, and a major one at that. Consider the following simple example:

/* Python code */
my_variable = 10
while my_variable > 0:
i = foo(my_variable)
if i < 100:
my_variable++
else
my_varaible = (my_variable + i) / 10 // spelling error intentional

As you can see in the above code, my_varaible is a spelling mistake that the programmer could have very well made. The problem here is that, since Python is dynamically typed, it will not return an error, but instead will create a new variable called my_varaible. So, now we have two variables: my_variable and my_varaible. This obviously is a serious problem; some would suggest that forced variable declaration is an important requirement in any programming language.

=== Static Typed Behavior in Dynamic Typed Languages ===
Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. Consider the following Perl example:

/* Perl code */

$sum = 10;
print $sum;

The above code will run without any problem, and will print 10 to the console. Note that here, we have not initialized the variable sum; this exemplifies the dynamic typing characteristic of Perl. To enforce variable declaration, we make use of the strict pragma as follows:

/* Perl code */

use strict;
$sum = 10;
print $sum;

The above code fragment will return the following error when you try to run it:

Global symbol "$num" requires explicit package name at perl.pl line 2.
Execution of perl.pl aborted due to compilation errors.

To rectify the above error, we are forced to declare the variable num as follows:

/* Perl code */

use strict;
my $num; // forced declaration
$sum = 10;
print $sum;

The above codes are specific to Perl; not all programming languages have a way to enforce variable declaration: Python, for example doesn't have a way to enforce variable declaration. However, there is a tool, called "pychecker" (available here), that can be used to "detect" stray variables; this is, of course, far from a desirable solution.

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-14T02:40:10Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

== Definition ==
=== What is The Type System? ===
A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.
=== Classification of Type Checking ===
The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.
===Mixing Static and Dynamic Typing ===
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Fundamentals ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

=== Static Typing and Dynamic Typing versus Strong Typing and Weak Typing ===
Static and dynamic typing, and strong and weak typing, are two totally different concepts, which, unfortunately, are very often confused. It is erroneous to say that a language that is static or dynamic typed cannot be strong or weak typed. Static and dynamic typing, and strong and weak typing, are different forms of classification of programming languages, and one of each class necessarily characterizes a given language. It is thus imperative to discuss strong and weak typing vis-a-vis static and dynamic typing.

Programming languages that exhibit "strong typing" are "strong typed," and those that exhibit "weak typing" are "weak typed".

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]].

== Examples ==
=== Is Dynamic Typing Good? ===
In a dynamic typed language, you don't have to initialize variables, which is a big bonus for many developers. Programmers like the fact that you can use a variable at will when required (without having to initialize it). Dynamic typing is characteristic of many of the scripting languages: Perl, PHP, Python, etc. Dynamic typing, in fact, does save you from writing a few "extra" lines of code, which, in turn, means less time spent writing code.

The very characteristic of dynamic typed languages that appeals to many developers is also a pitfall, and a major one at that. Consider the following simple example:

/* Python code */
my_variable = 10
while my_variable > 0:
i = foo(my_variable)
if i < 100:
my_variable++
else
my_varaible = (my_variable + i) / 10 // spelling error intentional

As you can see in the above code, my_varaible is a spelling mistake that the programmer could have very well made. The problem here is that, since Python is dynamically typed, it will not return an error, but instead will create a new variable called my_varaible. So, now we have two variables: my_variable and my_varaible. This obviously is a serious problem; some would suggest that forced variable declaration is an important requirement in any programming language.

=== Static Typed Behavior in Dynamic Typed Languages ===
Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. Consider the following Perl example:

/* Perl code */
$sum = 10;
print $sum;

The above code will run without any problem, and will print 10 to the console. Note that here, we have not initialized the variable sum; this exemplifies the dynamic typing characteristic of Perl. To enforce variable declaration, we make use of the strict pragma as follows:

/* Perl code */
use strict;
$sum = 10;
print $sum;

The above code fragment will return the following error when you try to run it:

Global symbol "$num" requires explicit package name at perl.pl line 2.
Execution of perl.pl aborted due to compilation errors.

To rectify the above error, we are forced to declare the variable num as follows:

/* Perl code */
use strict;
my $num; // forced declaration
$sum = 10;
print $sum;

The above codes are specific to Perl; not all programming languages have a way to enforce variable declaration: Python, for example doesn't have a way to enforce variable declaration. However, there is a tool, called "pychecker" (available here), that can be used to "detect" stray variables; this is, of course, far from a desirable solution.

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-14T02:30:39Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

== Definition ==
=== What is The Type System? ===
A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.
=== Classification of Type Checking ===
The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.
===Mixing Static and Dynamic Typing ===
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Fundamentals ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]].

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-14T02:29:41Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

== Definition ==
=== What is The Type System? ===
A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.
=== Classification of Type Checking ===
The process of verifying and enforcing the constraints of types – type checking – may occur either at compile-time (a static check) or run-time (a dynamic check). In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.
===Mixing Static and Dynamic Typing ===
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]].

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T21:25:49Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]]
.

== Polymorphism and types ==
The term "polymorphism" refers to the ability of code to act on values of multiple types, or to the ability of different instances of the same data-structure to contain elements of different types. Type systems that allow polymorphism generally do so in order to improve the potential for code re-use: in a language with polymorphism, programmers need only implement a data structure such as a list or an associative array once, rather than once for each type of element with which they plan to use it. For this reason computer scientists sometimes call the use of certain forms of polymorphism generic programming. The type-theoretic foundations of polymorphism are closely related to those of abstraction, modularity and (in some cases) subtyping.

=== Duck Typing ===
In "duck typing", [4] a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must implement the method called. One way of looking at this is that in duck typing systems the type of an object is intrinsic to the object and is determined by what methods it implements, and hence that a duck typing system is by definition type-safe since one can only invoke operations an object actually implements. Another way of looking at this is that the object is a member of several types, including a type that describes the fact that it "has a method m." Type checking however occurs only on demand at runtime, every time the method m needs to be executed, not at compile-time or load-time.

Duck typing differs from structural typing in that, if the part (of the whole module structure) needed for a given local computation is present at runtime, the duck type system is satisfied in its type identity analysis. On the other hand, a structural type system would require the analysis of the whole module structure at compile-time to determine type identity or type dependence.

Duck typing differs from a nominative type system in a number of aspects. The most prominent ones are that, for duck typing, type information is determined at runtime (as contrasted to compile-time) and the name of the type is irrelevant to determine type identity or type dependence; only partial structure information is required for that, for a given point in the program execution.

Initially coined by Alex Martelli in the Python community, duck typing uses the premise that (referring to a value) "if it walks like a duck, and quacks like a duck, then it is a duck".

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Summary ==
There are a lot of discussions all over the internet about static vs dynamic languages. Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. Static typing and dynamic typing, are topics of programming language design that are not always clearly defined and, as a result, are not very well understood, especially for languages with mixing static and dynamic typing. For example, Perl is a dynamic typed programming language. However, it provides a means to "simulate" static typing by means of a pragma called strict. This article has given you an insight into the concepts of static and dynamic typing.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T20:38:53Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]]
.

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.

[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

[http://www.google.com/url?sa=t&source=web&cd=9&ved=0CD0QFjAI&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.69.5966%26rep%3Drep1%26type%3Dpdf&rct=j&q=static%20and%20dynamic%20typing&ei=qx2yTPfgFcWclgfGs5CAAg&usg=AFQjCNFl0eYeI_vgs6nJD4V0TNRsBlMTEg] Static Typing Where Possible, Dynamic Typing When Needed:
The End of the Cold War Between Programming Languages, Erik Meijer and Peter Drayton.

[http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list] Template:Type system cross reference list, from Wikipedia.

[http://www.google.com/#hl=en&source=hp&biw=1280&bih=760&q=static+and+dynamic+typing&aq=0&aqi=g2&aql=&oq=static+and+dynamic+typ&gs_rfai=C4_IOqB2yTOLZMYOIyAT7kYmCCgAAAKoEBU_QIQIR&fp=dc2ab5d7430ebd84] Dynamic vs. Static Typing — A Pattern-Based Analysis, Pascal Costanza, March, 2004.

[http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5523694&tag=1] Including both static and dynamic typing in the same programming language, Ortin, F.; Zapico, D.; Perez-Schofield, J.B.G.; Garcia, M.; Aug, 2010.

[http://www.artima.com/weblogs/viewpost.jsp?thread=7590] Typing: Strong vs. Weak, Static vs. Dynamic, by Aahz, July, 2003.

[http://stackoverflow.com/questions/125367/dynamic-type-languages-versus-static-type-languages] Dynamic type languages versus static type languages, Sep, 2009.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T20:22:12Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Static typed programming languages are those in which variables need not be defined before they're used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they're employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don't get converted; you just read them assuming they are another type.

Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:

/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;

The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.

=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they're used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:

/* Python code */
num = 10 // directly using the variable

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]]
.

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

== Reference ==
[http://articles.sitepoint.com/article/typing-versus-dynamic-typing] Introduction to Static and Dynamic Typing, Premshree Pillai, June, 2004.
[http://en.wikipedia.org/wiki/Type_system] Type system, from Wikipedia.

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T20:15:59Z

Paullei:

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T20:14:43Z

Paullei:

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T20:02:16Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Statically typed languages include Ada, AS3, C, C++, C#, Eiffel, F#, Go, JADE, Java, Fortran, Haskell, ML, Objective-C, Pascal, Perl. They will reject some programs that may be well-behaved at run-time, but that cannot be statically determined to be well-typed. For example, even if an expression <complex test> always evaluates to true at run-time, a program containing the code

if <complex test> then 42 else <type error>

will be rejected as ill-typed, because a static analysis cannot determine that the else branch won't be taken.
=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type. Dynamically typed languages include Erlang, Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (with respect to user-defined types but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk and Tcl. Compared to static typing, dynamic typing can be more flexible (e.g. by allowing programs to generate types and functionality based on run-time data), though at the expense of fewer a priori guarantees. This is because a dynamically typed language accepts and attempts to execute some programs which may be ruled as invalid by a static type checker. The term "dynamic language" means something different ("runtime dynamism") and a dynamic language is not necessarily dynamically typed.

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler.

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]]
.

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

File:Typereference.jpg

2010-10-10T19:47:44Z

Paullei:

CSC/ECE 517 Fall 2010/ch3 3i ls

2010-10-10T19:40:54Z

Paullei:

Mixing static and dynamic code other than Ruby and Java

A programming language is a notation for writing programs, which are specifications of a computation or algorithm. Some, but not all, authors restrict the term "programming language" to those languages that can express all possible algorithms. A type system defines how a programming language classifies values and expressions into types, how it can manipulate those types and how they interact. The goal of a type system is to verify and usually enforce a certain level of correctness in programs written in that language by detecting certain incorrect operations. Any decidable type system involves a trade-off: while it rejects many incorrect programs, it can also prohibit some correct, albeit unusual programs. In order to bypass this downside, a number of languages have type loopholes, usually unchecked casts that may be used by the programmer to explicitly allow a normally disallowed operation between different types. In most typed languages, the type system is used only to type check programs, but a number of languages, usually functional ones, perform type inference, which relieves the programmer from writing type annotations. The formal design and study of type systems is known as type theory.

In static typing all expressions have their types determined prior to the program being run (typically at compile-time). For example, 1 and (2+2) are integer expressions; they cannot be passed to a function that expects a string, or stored in a variable that is defined to hold dates. Statically typed languages can be either manifestly typed or type-inferred. In the first case, the programmer must explicitly write types at certain textual positions (for example, at variable declarations). In the second case, the compiler infers the types of expressions and declarations based on context. Most mainstream statically typed languages, such as C++, C# and Java, are manifestly typed. Complete type inference has traditionally been associated with less mainstream languages, such as Haskell and ML. However, many manifestly typed languages support partial type inference; for example, Java and C# both infer types in certain limited cases.

Dynamic typing, also called latent typing, determines the type-safety of operations at runtime; in other words, types are associated with runtime values rather than textual expressions.As with type-inferred languages, dynamically typed languages do not require the programmer to write explicit type annotations on expressions. Among other things, this may permit a single variable to refer to values of different types at different points in the program execution. However, type errors cannot be automatically detected until a piece of code is actually executed, making debugging more difficult. Ruby, Lisp, JavaScript, and Python are dynamically typed.

The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations, the support of runtime type tests, a form of dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.
== Introduction ==
In computer science, a type system may be defined as a tractable syntactic framework for classifying phrases according to the kinds of values they compute. A type system associates types with each computed value. By examining the flow of these values, a type system attempts to prove that no type errors can occur. The type system in question determines what constitutes a type error, but a type system generally seeks to guarantee that operations expecting a certain kind of value are not used with values for which that operation makes no sense.

Assigning data types (typing) gives meaning to sequences of bits. Types usually have associations either with values in memory or with objects such as variables. Because any value simply consists of a sequence of bits in a computer, hardware makes no intrinsic distinction even between memory addresses, instruction code, characters, integers and floating-point numbers, being unable to discriminate between them based on bit pattern alone. Associating a sequence of bits and a type informs programs and programmers how that sequence of bits should be understood.

Major functions provided by type systems include:
*Safety: Use of types may allow a compiler to detect meaningless or probably invalid code.
*Optimization – Static type-checking may provide useful compile-time information.Optimization – Static type-checking may provide useful compile-time information.
*Abstraction (or modularity) – Types allow programmers to think about programs at a higher level than the bit or byte, not bothering with low-level implementation.

Type safety contributes to program correctness, but cannot guarantee it unless the type checking itself becomes an undecidable problem. Depending on the specific type system, a program may give the wrong result and be safely typed, producing no compiler errors. For instance, division by zero is not caught by the type checker in most programming languages; instead it is a runtime error. To prove the absence of more general defects, other kinds of formal methods, collectively known as program analysis, are in common use, as well as software testing—a widely used empirical method for finding errors that the type checker cannot detect.

== Static Typing vs. Dynamic Typing ==
=== Static Typing ===
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time. Statically typed languages include Ada, AS3, C, C++, C#, Eiffel, F#, Go, JADE, Java, Fortran, Haskell, ML, Objective-C, Pascal, Perl. They will reject some programs that may be well-behaved at run-time, but that cannot be statically determined to be well-typed. For example, even if an expression <complex test> always evaluates to true at run-time, a program containing the code

if <complex test> then 42 else <type error>

will be rejected as ill-typed, because a static analysis cannot determine that the else branch won't be taken.
=== Dynamic Typing ===
A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type. Dynamically typed languages include Erlang, Groovy, JavaScript, Lisp, Lua, Objective-C, Perl (with respect to user-defined types but not built-in types), PHP, Prolog, Python, Ruby, Smalltalk and Tcl. Compared to static typing, dynamic typing can be more flexible (e.g. by allowing programs to generate types and functionality based on run-time data), though at the expense of fewer a priori guarantees. This is because a dynamically typed language accepts and attempts to execute some programs which may be ruled as invalid by a static type checker. The term "dynamic language" means something different ("runtime dynamism") and a dynamic language is not necessarily dynamically typed.

== Mixing Static and Dynamic Typing ==
The presence of static typing in a programming language does not necessarily imply the absence of all dynamic typing mechanisms. For example, Java, and various other object-oriented languages, while using static typing, require for certain operations (downcasting) the support of runtime type tests, a form of dynamic typing. See programming language for more discussion of the interactions between static and dynamic typing.

As of the 4.0 Release, the .NET Framework supports a variant of dynamic typing via the System.Dynamic namespace whereby a static object of type 'dynamic' is a placeholder for the .NET runtime to interrogate its dynamic facilities to resolve the object reference.

The choice between static and dynamic typing requires trade-offs.

Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus what proportion of those bugs which are written would be caught by static typing. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases. The value of static typing, then, presumably increases as the strength of the type system is increased. Advocates of dependently typed languages such as Dependent ML and Epigram have suggested that almost all bugs can be considered type errors, if the types used in a program are properly declared by the programmer or correctly inferred by the compiler. [3]

Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce optimized machine code. Further, compilers for statically typed languages can find assembler shortcuts more easily. Some dynamically typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization.

By contrast, dynamic typing may allow compilers to run more quickly and allow interpreters to dynamically load new code, since changes to source code in dynamically typed languages may result in less checking to perform and less code to revisit. This too may reduce the edit-compile-test-debug cycle.

Statically typed languages which lack type inference (such as Java and C) require that programmers declare the types they intend a method or function to use. This can serve as additional documentation for the program, which the compiler will not permit the programmer to ignore or permit to drift out of synchronization. However, a language can be statically typed without requiring type declarations (examples include Haskell, Scala and to a lesser extent C#), so this is not a necessary consequence of static typing.

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

Dynamic typing is used in Duck typing which can support easier code reuse.

Dynamic typing typically makes metaprogramming more effective and easier to use. For example, C++ templates are typically more cumbersome to write than the equivalent Ruby or Python code.[citation needed] More advanced run-time constructs such as metaclasses and introspection are often more difficult to use in statically typed languages.

The following table shows the type system cross reference list.
[[Image:typereference.jpg|center|type system cross reference list.]]

== Programming Style ==
Some programmers prefer statically typed languages; others prefer dynamically typed languages. Statically typed languages alert programmers to type errors during compilation, and they may perform better at runtime. Advocates of dynamically typed languages claim they better support rapid prototyping and that type errors are only a small subset of errors in a program. Likewise, there is often no need to manually declare all types in statically typed languages with type inference; thus, the need for the programmer to explicitly specify types of variables is automatically lowered for such languages; and some dynamic languages have run-time optimisers that can generate fast code approaching the speed of static language compilers, often by using partial type inference.

CSC/ECE 517 Fall 2010/ch2 2c ls

2010-09-22T04:35:07Z

Paullei:

= Introduction =
In object-oriented programming (oop), inheritance is a way to reuse code by creating collections of attributes and beheaviors called objects, which can be classified as class-based inheritance and prototype-based inheritance. In class-based inheritance, objects are defined by classes which can inherit other classes; and in contrast, in prototype-based inheritance, objects can be defined directly from other objects without the need to define any classes. Particularly, prototype-based inheritance is a code reuse behavior which is performed via a process of cloning existing objects that serve as prototypes.
= "Class-based" Vs. "Prototype-Based" =
We first compare the whole "class" with "prototype". The idea originally began in Simula, where with a class-based method each class represented a set of objects that share the same state space and the same operations, thereby forming an equivalence class. Later object-oriented languages wanted to be able to use static type checking, so we got the notion of a fixed class set at compile time.
In "class-based" inheritance, copying happens at compile time. In prototype-based inheritance, the operations are stored in the prototype data structure, which is copied and modified at run time. Abstractly, though, a class is still the equivalence class of all objects that share the same state space and methods. When you add a method to the prototype, you're effectively making an element of a new equivalence class.

In class-based languages a new instance is constructed through the class's constructor and an optional set of constructor arguments. The resulting instance is modeled on the layout and behavior dictated by the chosen class.

In prototype-based systems there are two methods of constructing new objects, through cloning of an existing object, and through ex nihilo ("from nothing") object creation. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.

= Pros for Prototype-base Inheritance =
Class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes. As such, many prototype-based systems encourage the alteration of prototypes during runtime, whereas only very few class-based object-oriented systems (such as the dynamic object-oriented system, Smalltalk, Python, Perl, or Ruby) allow classes to be altered during the execution of a program. Advocates argue the following pros for prototype-based inheritance:
1, Suitable in loosely typed environments, no need to define explicit types.
2, Makes it incredibly easy to implement singleton pattern ( compare javascript and java in this regard.)
3, Provides ways of applying a method of an object in the context of a different object, adding and replacing methods dynamically from an object etc.
= Cons for Prototype-base Inheritance =
Advocates of class-based inheritance criticize prototype-based inheritance often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see Datatype). Usually, such concerns involve: correctness, safety, predictability, and efficiency.

= References =
* (1) Günther Blaschek, Omega: Statically Typed Prototypes.
* (2) John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0521780985, chapter 10 "Concepts in object-oriented languages"
* (3) Antero Taivalsaari, Classes vs. Prototypes: Some Philosophical and Historical Observations
* [http://publications.ai.mit.edu/ai-publications/pdf/AIM-602.pdf (4)]