Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:13:22Z

Sarao: /* Listing all the methods unique to an object */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4f_sl#Introduction Reflection]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end

Comments for the program:
The above program is used to list all the methods unique to the object. Here it finds out all the methods and subtracts all the Super class methods.
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''[http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError]'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:08:33Z

Sarao: /* Responding to calls to undefined methods */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4f_sl#Introduction Reflection]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''[http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError]'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:07:27Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4f_sl#Introduction Reflection]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:07:00Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [[reflection]]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:04:04Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [[reflection]]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [[Metaprogramming]] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:02:23Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature [[reflection]]. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and [[Meta-programming]] is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-30T01:01:31Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of [[dynamic languages]] such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the [http://en.wikipedia.org/wiki/Java_Virtual_Machine Java virtual machine]. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set [http://en.wikipedia.org/wiki/Application_programming_interface APIs] defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with [http://gcc.gnu.org/ GCC] (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Reflection drawbacks in general=

In general, there are several drawbacks of using reflection in object-oriented programming languages:

*Lose all the compile-check features, consequently lose in performance.

*There are also some security restrictions to call reflection methods.

*Lots of boilerplate codes, comes at a speed cost.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection provides objects that encapsulate assemblies, modules, and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object. You can then invoke the type's methods or access its fields and properties. There are also some drawbacks for using reflection we metioned above. In all, reflection is a very useful tool for OOP languages.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection for computer programming]

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T23:20:19Z

Sarao: /* Conclusion */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Summary of the Article=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection can be used for observing and/or modifying program execution at runtime. It allows inspection of classes, interfaces, fields and methods at runtime without knowing the names of the interfaces, fields, methods at compile time. It also allows instantiation of new objects and invocation of methods.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T23:19:44Z

Sarao:

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection can be used for observing and/or modifying program execution at runtime. It allows inspection of classes, interfaces, fields and methods at runtime without knowing the names of the interfaces, fields, methods at compile time. It also allows instantiation of new objects and invocation of methods.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems

=Further reading=
* Ira R. Forman and Nate Forman, ''Java Reflection in Action'' (2005), ISBN 1-932394-18-4
* Ira R. Forman and Scott Danforth, ''Putting Metaclasses to Work'' (1999), ISBN 0-201-43305-2

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T23:18:39Z

Sarao:

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks in Java==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks in C++==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

In this wiki page, we describe the reflection feature for object-oriented languages. We focus on introducing the reflection in Ruby, Java and C++ languages. Reflection can be used for observing and/or modifying program execution at runtime. It allows inspection of classes, interfaces, fields and methods at runtime without knowing the names of the interfaces, fields, methods at compile time. It also allows instantiation of new objects and invocation of methods.

=References=
<references/>

=External links=
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://www.laputan.org/#Reflection Brian Foote's pages on Reflection in Smalltalk]
*[http://java.sun.com/docs/books/tutorial/reflect/index.html Java Reflection Tutorial] from Sun Microsystems

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T13:07:00Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby<ref>The Ruby cookbook by O'reilly publishers</ref>. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods:==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object:==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method:==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code:==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods:==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

===General Drawbacks:===
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

==='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''===

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T13:03:31Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

==Finding an Object’s class or super class==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

==Listing an object’s methods:==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

==Listing all the methods unique to an object:==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

==Getting a reference to a method:==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

==Fixing bugs in someone else’s code:==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

==Responding to calls to undefined methods:==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

===General Drawbacks:===
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

==='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''===

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-20T13:01:42Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

=='''Finding an Object’s class or super class'''==

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

=='''Listing an object’s methods:'''==

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

=='''Listing all the methods unique to an object:'''==

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

=='''Getting a reference to a method:'''==

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

=='''Fixing bugs in someone else’s code:'''==

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

=='''Responding to calls to undefined methods:'''==

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

===General Drawbacks:===
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

==='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''===

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:33:02Z

Sarao: /* Limitations of using Reflection either explicitly described by programmer or extracted from debugging info: */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

===General Drawbacks:===
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

==='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''===

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:32:47Z

Sarao: /* General Drawbacks: */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

===General Drawbacks:===
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:32:34Z

Sarao: /* General Drawbacks: */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

=General Drawbacks:=
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:32:12Z

Sarao: /* Drawbacks of Reflection */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

==General Drawbacks:==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=='''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:31:19Z

Sarao: /* Drawbacks of Reflection */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

'''Limitations of using Reflection either explicitly described by programmer or extracted from debugging info:'''

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations to both of the techniques'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:28:33Z

Sarao: /* Drawbacks of Reflection */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitations'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T20:23:14Z

Sarao: /* Introduction */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to examine aspects of the program from within the program itself. Java calls this feature reflection. This feature is supported by many languages. In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the use of reflection and Meta-programming is to save the designer from having to write repetitive code.

For instance, sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created. One way to accomplish this is to write conditional loops and create the object. But if there are too many classes then this would become messy. This the point where reflection comes to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror. We use reflection to examine parts of our programs that aren't normally visible from where we stand.

Commonly, Reflection helps us get to know about:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. A reference to the module includes.

Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:20:57Z

Sarao:

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

'''Reflection in terms of Ruby:'''

In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. To know the inheritance structure.

d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:19:43Z

Sarao:

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

'''Reflection in terms of Ruby:'''

In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. To know the inheritance structure.

d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:18:13Z

Sarao: /* Definition of Reflection */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:

a. Which methods can be called from an Object?

b. Grab one of the methods of an Object and pass it on to another as a code block.

c. To know the inheritance structure.

d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:17:41Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

'''5.Fixing bugs in someone else’s code:'''

This is used when you know which method has a bug and you know how to solve the issue, but you don’t have access to that method or don’t want to change the source file.

In this case, we can extend the class from within our program and overwrite the buggy method with our own implementation.

Example:
Find the buggy multiplier method :
<pre>
class Multiplier
def double_your_pleasure(pleasure)
return pleasure * 3 # FIXME: Actually triples your pleasure.
end
end
</pre>

<pre>
m = Multiplier.new
m.double_your_pleasure(6) # => 18
</pre>

Now we can reopen the class, alias the buggy implementation to another name and redefine it again.

<pre>
class Multiplier
alias :double_your_pleasure_BUGGY :double_your_pleasure
def double_your_pleasure(pleasure)
return pleasure * 2
end
end
</pre>

<pre>
m.double_your_pleasure(6) # => 12
m.double_your_pleasure_BUGGY(6) # => 18
</pre>

'''6.Responding to calls to undefined methods:'''

Rather than Ruby raising a ''NoMethodError'' when someone calls an undefined method, we want to intercept the method call and do something else with that.
We can do this by defining a ''method_missing'' method for our class. Whenever someone calls a function which is not defined, then method_missing is called.

Example:
<pre>
class MyClass
def defined_method
'This method is defined.'
end

def method_missing(m, *args)
"Sorry, I don't know about any #{m} method."
end
end

o = MyClass.new
o.defined_method # => "This method is defined."
o.undefined_method
# => "Sorry, I don't know about any undefined_method method."
</pre>

Most of the times, ''method_missing'' is implemented to delegate the implementation of methods to another class. For example, if a class implements ''method_missing'' method to catch all such not defined errors and then uses send to delegate it to another object.

These are some of the most important usages of Reflection in Ruby.

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:13:11Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

A method object can also be stored in a variable and passed onto other methods as arguments. This is useful to implement callbacks and listeners. A method can also be used as a block.

Example:
<pre>
s = "sample string"
replacements = { "a" => "i", "tring" => "ubstitution" }

replacements.collect(&s.method(:gsub))
# => ["simple string", "sample substitution"]

</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:12:18Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''

If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''

When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

'''4.Getting a reference to a method:'''

The ''Object#methods'' returns an array of strings, each containing one of the methods supported by that particular object. We can pass any of those object’s ''method'' method and get a method object corresponding to that ''method'' of that object.

Invoke the method's ''Method#call'' method, and it's just like calling the object's method directly.

Example:
<pre>
1.succ # => 2
1.method(:succ).call # => 2

[1,2,3].method(:each).call { |x| puts x }
# 1
# 2
# 3

</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:10:09Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''
If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

'''3.Listing all the methods unique to an object:'''
When we check for all the methods available for a class, there are multiple methods which are defined in the object’s super class and mixed-in modules. But, if we need only the methods defined by that object.

Then it can be done by subtracting the instance methods defined by the object’s super class leaving behind only the instance methods defined by the direct class.

Example:
<pre>
class Object
def
my_methods_direct
my_super = self.class.superclass
return my_super ? methods - my_super.instance_methods : methods
end
end
</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:07:19Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''
If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

We can also list all the public, private and protected methods of a particular object.

Example:
<pre>
String.private_instance_methods.sort
# => ["Array", "Float", "Integer", "String", "'", "abort", "at_exit",
# "autoload","autoload?", "binding", "block_given?", "callcc", … ]
</pre>

There is another powerful usage where the user can check if a particular method is supported by the object. This can be done using the ''Object.respond_to?''

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:06:12Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

'''2.Listing an object’s methods:'''
If there is an unfamiliar object and the user wants to know the supported methods for that object, then he can use the methods call.

Example:
<pre>
Object.methods
# => ["name", "private_class_method", "object_id", "new",
# "singleton_methods", "method_defined?", "equal?", … ]
</pre>

The output can also be sorted using the sort method.

Example:
<pre>
Object.methods.sort
# => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",
# "__id__", "__send__", "allocate", "ancestors", … ]
</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:04:21Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''

Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:03:52Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2010/ch4 4f sl
----
=Introduction=

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection.
Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

* what objects it contains,

* the current class hierarchy,

* the contents and behaviors of objects, and

* Information on methods.

=Definition of Reflection=
In languages like Ruby, the classes and Objects exhibit highly dynamic behavior. Probably the most interesting and useful aspect of the Ruby programming is the use of reflection and Meta-programming to save the designer from having to write repetitive code.

Reflection allows us to treat classes and methods as objects. Some of the important uses of reflection are:
a. Which methods can be called from an Object?
b. Grab one of the methods of an Object and pass it on to another as a code block.
c. To know the inheritance structure.
d. A reference to the module includes.

These are some of the basic and important uses. Basically Reflection allows the user to interactively examine an unfamiliar object or structure.

=Reflection in Ruby=
There are multiple usages of Reflection in Ruby. Some important instances of usage of Reflection in Ruby are shown below:

'''1.Finding an Object’s class or super class'''
Use the ''Object#class'' method to get the class of an object as a Class object. Use ''Class#superclass'' to get the parent Class of a Class object.

Example:
<pre>
'a string'.class # => String
'a string'.class.name # => "String"
'a string'.class.superclass # => Object
String.superclass # => Object
String.class # => Class
String.class.superclass # => Module
'a string'.class.new # => ""
</pre>

Ruby doesn’t support multiple inheritance as the language allows mixin Modules that simulate it. The Modules included by a given Class (or another Module) are accessible from the ''Module#ancestors'' method.

A class can have only one superclass , but it may have any number of ancestors.
Example:
<pre>
String.superclass # => Object
String.ancestors # => [String, Enumerable, Comparable, Object, Kernel]
Array.ancestors # => [Array, Enumerable, Object, Kernel]
MyArray.ancestors # => [MyArray, Array, Enumerable, Object, Kernel]
Object.ancestors # => [Object, Kernel]
</pre>

=Reflection in Java=

==Use of Reflection==
Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

'''Extensibility Features'''

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

'''Class Browsers and Visual Development Environments'''

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

'''Debuggers and Test Tools'''

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

'''A Simple Example'''

To see how reflection works, consider this simple example:

<pre>
import java.lang.reflect.*;
public class DumpMethods {
public static void main(String args[])
{
try {
Class c = Class.forName(args[0]);
Method m[] = c.getDeclaredMethods();
for (int i = 0; i < m.length; i++)
System.out.println(m[i].toString());
}
catch (Throwable e) {
System.err.println(e);
}
}
}
</pre>

For an invocation of:
<pre>
java DumpMethods java.util.Stack
</pre>

the output is:
<pre>
public java.lang.Object java.util.Stack.push(
java.lang.Object)
public synchronized
java.lang.Object java.util.Stack.pop()
public synchronized
java.lang.Object java.util.Stack.peek()
public boolean java.util.Stack.empty()
public synchronized
int java.util.Stack.search(java.lang.Object)
</pre>

==Drawbacks of Reflection==
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

'''Performance Overhead'''

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

'''Security Restrictions'''

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

'''Exposure of Internals'''

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

=Reflection in C++=

==Use of Reflection==

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

'''Compile-Time Reflection'''

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

'''Runtime Reflection'''

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

'''For example:'''

<pre>
#include "reflect.h"
#include "typedecl.h"

class A {
public:
int i;
char* pc;
double d;
protected:
long larr[10];
A** ppa;
A* pa;
public:
RTTI_DESCRIBE_STRUCT((RTTI_FIELD(i, RTTI_FLD_PUBLIC),
RTTI_PTR(pc, RTTI_FLD_PUBLIC),
RTTI_FIELD(d, RTTI_FLD_PUBLIC),
RTTI_ARRAY(larr, RTTI_FLD_PROTECTED),
RTTI_PTR_TO_PTR(ppa, RTTI_FLD_PROTECTED),
RTTI_PTR(pa, RTTI_FLD_PROTECTED)));
};

RTTI_REGISTER_STRUCT(A, 0);
</pre>

==Drawbacks of Reflection==

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

'''Common limitation'''

*It is possible to create instance of the object only using default constructor.

*API doesn't support enums, unions and bit fields.

*API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

'''Limitation of extracting information from descriptors written by programmer'''

*Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

*Methods can not have more than 5 parameters

*It is not possible to describe static methods and fields.

*Each class should have public default constructor or have no constructors at all.

'''Limitations of extracting types from debug information'''

*This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

*It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

*There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

*Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

*No field qualifiers (such as const, volatile,...) are currently extracted.

=Conclusion=

=References=
<references/>

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:03:10Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:02:51Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:02:34Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:02:12Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:01:06Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T05:00:17Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T04:59:25Z

Sarao: /* Reflection in Ruby */

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T04:58:57Z

Sarao:

CSC/ECE 517 Fall 2011/ch4 4f sl

2011-10-19T04:53:49Z

Sarao:

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:14:07Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems.It extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-26T00:12:15Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Choice of Version Control Systems ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.
There are a number of solutions which are available for programmers.Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.
The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

Command to create a new view: cleartool mkview -tag atag storage-location

Command to create a new file: cleartool mkelem <file_name>

Command to create a new branch: cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing: cleartool co -nc <file_name>

Command to check in a file after editing: cleartool ci -nc <file_name>

Command to check the current working view: ct pwv

Command to view/edit the current config spec for the view: ct catcs /edcs

Command to merge and deliver the code changes: cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file: cleartool rmelem <file_name>

Command to delete a view: cleartool rmview <view_name>

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:39:20Z

Sarao: /* ClearCase Version Management System */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:38:58Z

Sarao: /* Comparison of Version Control Applications */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== ClearCase Version Management System =====

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.
These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]
===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==References==
<references/>

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:31:05Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''

Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''

Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:30:11Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view:''' ct mkview -tag <view_name>'''
Sample command to create a new file:'''ct mkelem <file_name>'''

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: '''ct co -nc <file_name>'''
Sample command to check in a file:''' ct ci -nc <file_name>''' (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:29:03Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

Sample command to create a new view: ct mkview -tag <view_name>
Sample command to create a new file: ct mkelem <file_name>

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

Sample command to check out a file: ct co -nc <file_name>
Sample command to check in a file: ct ci -nc <file_name> (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:22:23Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]
Sample command to create a new view: ct mkview -tag <view_name>

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]
Sample command to check out a file: ct co -nc <file_name>
Sample command to check in a file: ct ci -nc <file_name> (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:21:42Z

Sarao: /* Sample Workflow involving Clearcase */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]

==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]
Sample command to create a new view: ct mkview -tag <view_name>

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]
Sample command to check out a file: ct co -nc <file_name>
Sample command to check in a file: ct ci -nc <file_name> (when you are working in the same branch where the file is checked out).

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]

CSC/ECE 517 Fall 2011/ch1 1f rs

2011-09-25T23:02:54Z

Sarao: /* See also */

=='''Comparison of Version Control Systems : The Programmer View'''==

__TOC__

== Introduction ==
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

== Choice of Version Control Systems ==
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.

The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

== Comparison of Version Control Systems==
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.

[[Image:CVS.png|thumb|150px|alt=Distributed Version Control]]
==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.

==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

==== Summary of Centralized versus Distributed Approach ====

{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}

== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====

===== RCS: The Revision Control System (RCS)=====

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]

===== CVS: The Concurrent Versions System (CVS)=====

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.

More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]

===== SVN: Sub Version (SVN)=====

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at [http://subversion.apache.org/ SVN]

===== Git:=====

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at [http://git-scm.com/ Git]

===== Mercurial:=====

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]

==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
| C
| File
| No
| No
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
| C
| Tree
| Yes
| Yes
| No
| Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
| C, Java, Perl
| File
| Partial
| Yes
| No
| Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
| C,Perl
| Tree
| Yes
| Partial
| Yes
| No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
| Python, C
| Tree
| Yes
| Yes
| Yes
| No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Feature
! Feature Description
|-
! Repository Model
| Describes the relationship between various copies of the source code repository.
|-
! Concurrency Model
| Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
|-
! Programming Languages
| The coding language in which the application is being developed
|-
! Scope of Change
| Describes whether changes are recorded for individual files or for entire directory trees.
|-
! Atomic commits
| Refers to a guarantee that all changes made are merged, or that no change at all will be made.
|-
! File Renames
| Describes whether a system allows files to be renamed while retaining their version history.
|-
! Interactive Commits
| Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
|-
! Partial Checkout/clone
| Ability to check out or clone only a specified subdirectory from a repository.
|}

==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------

{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|Rebase
|-
! RCS
| Not Supported
| Not Supported
| Not Supported
| co
| Not Supported
| rcsclean
| rcsmerge
| ci
| Not Supported
| Not Supported
|-
! CVS
| Not Supported
| Not Supported
| Not Supported
| checkout
| add
| rm
| update -j
| commit
| rm, update
| Not Supported
|-
! SVN
| svnadmin hotcopy
| svnadmin load
| svnadmin dump
| checkout
| add
| rm
| merge
| commit
| revert
| Not Supported
|-
! Clearcase
| Not Supported
| Not Supported
| Not Supported
| checkout
| mkelem
| rmelem
| merge
| checkin
| unco/rmver
| findmerge
|-
! Git
| Clone
| Fetch
| Push
| Clone
| add
| rm
| merge
| commit
| checkout
| rebase
|-
! Mercurial
| Clone
| Pull
| Push
| Clone
| add
| rm
| merge
| commit
| revert
| rebase
|}

{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! Command
! Command Description
|-
! Clone
| Create an identical instance of a repository
|-
! Pull
| Download revisions from a remote repository to a local repository
|-
! Push
| Upload revisions from a local repository to a remote repository
|-
! Checkout
| Create a local working copy from a (remote) repository
|-
! Add an element
| Mark specified files to be added to repository at next commit
|-
! Remove an element
| Mark specified files to be removed at next commit
|-
! Merge
| Apply the differences between two sources to a working copy path
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}

==== Sample Workflow involving Clearcase ====
------------------------------------------------------------------------------------------------------------------------------------------------
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.

'''Joining a UCM Project''': After project managers have established the UCM project environment, developers can then set up their work areas.
This is accomplished by joining the UCM project. More information about this can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_join_ucm_proj.htm here]

'''Working with views''': A view is the mechanism Rational ClearCase uses to provide access to specific versions of elements or specific parts of
code under source control. Rules are the basis to determine which version of each element is visible and accessible through the view for a developer. More information about views can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_views_intro.htm here]

'''Checking in files and checking out files''': Checking files in and out are two basic operations you will perform on a regular basis by a developer. Whenever the developer needs to edit a file, he has to checkout the file. And after completion of coding, he needs to check in the file. More information about the process can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_file_ci_co.htm here]

'''Delivering your work''': After testing your work in your private workspace, and you are sure that your work is error-free, you are ready to submit your work to the integration stream so that other project members can use the latest version of your work. More information about the procedure of delivering code can be found [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_deliver_wrk.htm here]

'''Merging your work''': After completion, the development branch must be merged to integration branch where software developed by different teams are merged and tested for seamless operation. More information about this procedure can be obtained [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.tutorial.doc/a_merge_wrk.htm here]

==See also==
[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]

[http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]

[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]

==References==
<references/>

==External links==
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]