Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-18T00:44:04Z

Kkalker:

==Generic Programming==
Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. This enables writing common set of functions which differ only in the types on which they operate. This reduces duplication. Software entities created using generic programming are known as ''generics'' in [http://en.wikipedia.org/wiki/Ada_(programming_language) Ada], [http://en.wikipedia.org/wiki/Eiffel_(programming_language) Eiffel], [http://en.wikipedia.org/wiki/Java_(programming_language) Java], [http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#], [http://en.wikipedia.org/wiki/F_Sharp_(programming_language) F#], and [http://en.wikipedia.org/wiki/Visual_Basic_.NET Visual Basic .NET]; parametric polymorphism in [http://en.wikipedia.org/wiki/ML_(programming_language) ML], [http://en.wikipedia.org/wiki/Scala_(programming_language Scala] and [http://en.wikipedia.org/wiki/Haskell_(programming_language) Haskell], [http://en.wikipedia.org/wiki/template_(programming) template]s in [http://en.wikipedia.org/wiki/C++ C++].

For example, given various data structures and several algorithms, the brute force way would be implement them for each data structure which would mean that various combinations of implementations will be necessary. Generic programming reduces this effort.


==Generics in Java==
===What are Generics?===
Generics were added to Java programming language as a part of J2SE 5.0 release in 2004. They allow programmers to develop generic and compile safe applications which enables a type or method to operate on objects of various type. This feature is well utilized while implementing [http://en.wikipedia.org/wiki/Java_Collections Java Collections]. The reason why people went into generic programming can be well explained using the below example:
<pre>
List list = new ArrayList();
list.add("name");
Integer num = (Integer)list.get(0);
</pre>
In this example, we insert a <code>String</code> into an <code>ArrayList</code> and retrieve element by typecasting with Integer wrapper class. This throws a runtime exception because of Illegal class cast. But if we use generics, runtime exceptions can be avoided and the compiler will be able to catch such issues which in turn help a programmer to build a bug free code. So if we convert the above code to use generic then it would look like this:
<pre>
List<String> list = new ArrayList<String>();
list.add("name");
Integer num = list.get(0); //line 1
</pre>
Here at line 1 the compiler throws an error because the compiler on seeing the declaration of ArrayList will be expecting the list to have just <code>String</code> and thereby the return type of <code>get</code> to be <code>String</code>.

===Implementing Generics:===
Java provides a feature which helps one to implement your own generic types and this will help to build more sophisticated and runtime error free applications. Consider the below example:
<code>
interface List<N> {
void add(N i);
Iterator<N> iterator();
}
interface Iterator<N> {
N next();
boolean hasNext();
}
class LinkedList<N> implements List<N> {
//Business Logic
}
</code>
So here, <code>N</code> can be replaced with any primitive data types or wrapper classes in the business logic. But we need to make sure that placeholders to be replaced with valid subtypes of Object. Generics implementation is not restricted for classes or interfaces, we can have for static/non static methods and constructors.

Example for generic methods:

<pre>
<T> void fromArrayToCollection(T[] a, Collection<T> c) {
for (T o : a) {
c.add(o); // Correct
}
}
</pre>
===Pros and Cons===
Pros:
<ol>
<li>Reduces the number of casts in the program, which in turn reduces the number of potential bugs in the program.</li>
<li>Improves code clarity and maintenance.</li>
</ol>
Cons:
<ol>
<li>Parameter type information is not available at run time.</li>
<li>The automatically generated casts may fail when interoperating with ill-behaved legacy code.</li>
</ol>

==Templates in C++==
===What are templates?===
Templates are functions that can operate with generic types which means that the functionality can be adapted for more than one type of data without repeating the entire code for each type.

===Overview===
Templates can be either function templates or class templates.
====Function Templates====
These are just like regular functions except that they can have arguments of different types. A single function definition works with different kinds of data types. During compile time, the actual functions are generated once the compiler knows the data type being used. This kind of template does not save any memory.

Example
<pre>
template <typename Type>
Type max(Type a, Type b) {
return a > b ? a : b;
}

#include <iostream>

int main()
{
// This will call max <int> (by argument deduction)
std::cout << max(3, 7) << std::endl;
// This will call max<double> (by argument deduction)
std::cout << max(3.0, 7.0) << std::endl;
// This type is ambiguous, so explicitly instantiate max<double>
std::cout << max<double>(3, 7.0) << std::endl;
return 0;
}
</pre>

====Class Templates====
A class template provides a specification for generating classes based on parameters. A class template is instantiated by passing a given set of types to it as template arguments.

Example
<pre>
template <class T>
class mypair {
T values [2];
public:
mypair (T first, T second)
{
values[0]=first; values[1]=second;
}
};
</pre>

===Features of C++ Templates===
Some of the features of C++ templates are:
<ol>
<li>
Implemented in the compiler.<ol><ul>No runtime overhead</ul><ul>Requires template source to be in headers</ul><ul>Latent typing means template instantiator does no type checking</ul></ol>
</li>
<li>Gloriﬁed macro facility<ol><ul>“Macros done right”/“Macros that look like classes”</ul></ol></li>
<li>
Can use template arguments for both classes and straight function</li>
<li>Template specialization<ol><ul>Speciﬁc implementation of a templated type or method</ul></ol></li>
<li>Pattern matching and text replacement<ol><ul>Declarative model (like [http://en.wikipedia.org/wiki/Prolog Prolog])</ul></ol></li>
</ol>

===Pros and Cons===
Usage of templates have both advantages and disadvantages.

Pros
<ol>
<li>Reduction in code size.</li>
<li>They are type-safe, that is, type-checking is done at compile time.</li>
</ol>

Cons
<ol>
<li>Since all compilers are not good at their support for templates, they may not be very portable.</li>
<li>Compilers generate additional code for each template type, this could lead to huge code if usage of templates is not checked.</li>
<li>Information hiding is not achieved as the code is all exposed in the header.</li>
</ol>

==Templates (C++) versus Generics (Java)==
We can compare templates in C++ versus generics in Java based on the following models of comparison,
1. Translation model - discussion based on the way generic code is translated.
2. Type model - discussion based on implementations in type interference, type aliasing and associated types.
3. Security model - discussion based on security loopholes, if any.
Let's look at these with some examples.

===Translation Model===
====Java====
One of the design reasons behind Java's generics was to provide backward compatibility of legacy Java code. To achieve this, Java implementation has adopted the same representation policy for the raw type and the parametric type. The parametric type Collection<T> can be passed safely where the corresponding raw type Collection is expected. Hence the translation model of Java Generics is based on the “type erasure” model, where the translation erases the generic type parameter, replaces them by the bounding type (Object) and inserts casts to the actual places of usage. In order for method overriding to work correctly, the translation process also adds “bridge methods”, as illustrated in the following example.
<pre>
class C<A> { abstract A id(A x); }
class D extends C<String> { String id(String x) { return x; } }
This will be translated to:
class C { abstract Object id(Object x); }
class D extends C {
String id(String x) { return x; }
// bridge method introduced by the translator to make
// overriding work correctly
Object id(Object x) { return id((String)x); }
}
</pre>

====C++====
The translation model of C++ is based on instantiation – no static type checking is done on the generic code. The compiler generates separate copies of the component (class or function) for each instantiation with a distinct type and the type checking is performed after instantiation at each call site. Type checking of the bound types can only succeed when the input types have satisfied the type requirements of the function template body. It is because of this, that misleading error messages are thrown in by the compiler when a generic component is instantiated with an improper type.

====Comparison====
The C++ model is loss-less in the sense that no type information is lost during runtime, though the implementation of the translation suffers from the drawbacks of the possibility of introducing code bloats and misleading error messages. On the other hand, the Java model emphasizes on retrofitting the raw types with the generic counterparts, but the type-erasure model delegates the generic types to “second class” status compared to the conventional types.

===Type Model===
====Java====
Type requirements can be defined on arguments as a set of formal abstractions – this feature is called constrained genericity. The generic types of the classes have to honor these requirements in order to participate in the valid instantiation. Java Generics use interfaces to represent a concept and employ the mechanism of subtyping to model a concept – any type T modeling a concept C will have to implement the corresponding interface.

<pre>
public interface VertexListGraph<Vertex,
VertexIterator extends Iterator<Vertex>> {
VertexIterator vertices();
int num_vertices();
}
public interface IncidenceGraph<Vertex, Edge,
OutEdgeIterator extends Iterator<Edge>> {
OutEdgeIterator out_edges(Vertex v);
int out_degree(Vertex v);
}
public interface VertexListAndIncidenceGraph<…>
extends VertexListGraph<…>, IncidenceGraph<…> {}
public class adjacency_list
implements VertexListAndIncidenceGraph<Integer,
Simple_edge<Integer>, Iterator<Integer>,
Integer, Iterator<simple_edge<Integer>>,
Integer, Iterator<simple_edge<Integer>>> {
……
}
</pre>

The implements clause makes the adjacency_list a model of Vertex List Graph and Incidence Graph concepts.

====C++====
C++ does not offer any means to constrain the template parameters. However, techniques for checking constraints in C++ have been implemented as a library using the notion of compile time assertions.

====Comparison====
Java Generics come without two of the very important features of generic programming – type aliasing and associated types. C++ templates offer both of them, type aliasing through typedefs and the associated types through the traits mechanism. Though typedef s are not part of
the C++ templates per se, but without them writing generic code often becomes extremely
verbose and error prone.

Java has no type aliasing as seen below:
<pre>
dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex, indirect_cmp<Vertex,
Distance, DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> vis
= new dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex,
indirect_cmp<Vertex, Distance,
DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> (Q, weight, predecessor,
distance, combine, compare, zero);
</pre>

Java has no support for associated types:
<pre>
// breadth_first_search prototype in C++
template <class VertexListGraph, class Buffer, class BFSVisitor,
class ColorMap>
void breadth_first_search
(const VertexListGraph& g,
typename graph_traits<VertexListGraph>::vertex_descriptor s,
Buffer& Q, BFSVisitor vis, ColorMap color)
// breadth_first_search prototype in Java
public static <Vertex,
Edge extends GraphEdge<Vertex>,
VertexIterator extends java.util.Iterator<Vertex>,
OutEdgeIterator extends java.util.Iterator<Edge>,
Vis extends Visitor,
ColorMap extends
ReadWritePropertyMap<Vertex,java.lang.Integer>,
QueueType extends Buffer<Vertex>>
void breadth_first_search(VertexListAndIncidenceGraph<Vertex,
Edge,VertexIterator,OutEdgeIterator> g,
Vertex s, Visitor vis, ColorMap color)
</pre>

===Security Model===
====Java====
Java Generics translation model replaces all generic types by the bound type, Object, thereby removing all type information from the runtime system. This is referred to as the homogeneous model of implementing Generics, since all generic types are mapped to a single supertype.

====C++====
C++ implements the heterogeneous model, where the compiler generates a separate copy of the type for each specific instantiation of the type parameter. Hence a generic container Stack<T> will generate separate concrete classes Stack<int> for integers, Stack<double> for double precision numbers, Stack<string> for string data type. While in Java, Stack<T> will be instantiated as Stack collection class.

<pre>
Class BroadcastList<C extends Channel> {
C channels[];
void add(C c) { … }
void broadcast(String s) {
int I;
for(I = 0; I < channels.length; i++)
channels[i].send(s);
}
……
}
Class EncryptedChannel extends Channel;
Class UnencryptedChannel extends Channel;
BroadcastList<EncryptedChannel> list = ……;
list.add(new EncryptedChannel());
(*)
list.broadcast(“Hello”);
</pre>

====Comparison====

Because of the homogeneous implementation, during instantiation of the generic class BroadCastList, C will not contain the exact type, since the translation of Java Generics will erase C. Hence it becomes vulnerable to a malicious program who can add an unencrypted channel to the list (possibly at position marked by (*)) through hand-written byte codes, which will bypass all compile time checking and the compiler generated run-time checks guaranteeing JDK 1.5 (beta) includes a workaround to prevent this security hole; it has a means of constructing a dynamically typesafe view of a specified collection (Collections.checkedCollection()). This ensures that any attempt to insert an element of incorrect type will result in a ClassCastException. But this approach introduces a counterintuitive programming model specifically to address an existing loophole in the security of the JVM.

In C++, this security loophole does not exist since strict type-checking is employed at the points of instantiation of templates. However, this heterogeneous translation model employed by C++ will not fit with the current security model of the Java virtual machine. The JVM offers two levels of visibility – global level (public) and package level. Hence in some cases it becomes impossible to find out the proper package where the instantiated class will be placed honoring the visibility model of the JVM.
==Evolution of Generics==
Here we take Java programming language as an example to explain evolution of generics. Generics were introduced with Java 1.5. However, before that, the codes were bulky and messy but the results were same. Rather than simply using a List<Integer> or Comparable<String>, developers had to deal with a significant amount of inheritance, casting, and instanceof testing. For example, an ArrayList to store only Integers pre-generics might look like the below snippet:
<pre>
public class IntegerList extends ArrayList{
public boolean add(Object o){
if(o instanceof Integer)
return super.add(o);
return false;
}

public Integer get(int index){
return (Integer)super.get(index);
}
}

</pre>
Generics allows to write more modular and reusable code that is adaptable to various datatypes, yet logically restrictive as well. Currently, generics are implemented using erasure, which means that the generic type information is not available at runtime, which makes some kind of code hard to write. Generics were implemented this way to support backwards compatibility with older non-generic code. Reified generics would make the generic type information available at runtime, which would break legacy non-generic code. Generics are implemented using erasure, in which generic type parameters are simply removed at runtime. That doesn't render generics useless, because you get typechecking at compile-time based on the generic type parameters, and also because the compiler inserts casts in the code based on the type parameters.
===Erasure v/s Reification===

Consider the below example, it won't work because of erasure.

<pre>
public class Test<Key, Val> {
public void test(Key key) {
}

public void test(Val value) {
}
}
</pre>
This would give a name clash error for having same erasure and one way to avoid the error is by renaming the method name but this will not the serve the purpose of overloading. Similarly, the below example would give errors because the JVM is not aware of the type T instead views it just as an Object.
<pre>
public class Test {
public <T> void f() {
T t = new T();
}
}
</pre>
So reified generics have support in the compiler for preserving type information whereas type erased generics don't have and that "remember" the class they were created with during runtime. Below are some of the reasons why Java should have reified generics:
<ol>
<li>Type argument erasure cripples frameworks that works with generic types and this results in horrid workarounds</li>
<li>Reified generics allows Typesafe narrowing. Currently in Java, we first test the type of the object using the instanceof operator, and then attempt to downcast it using a C-style typecast</li>
<li>Interoperability between statically-typed is difficult since few support reified generics.</li>
</ol>

But at the same time reified generics have issues and one of the main concern is incompatible with the current collections. So a test on <code>instanceof List<String></code> would now test that the object is an instance of <code>List</code> but also that its elements are of type <code>String</code>. This requires a lot of work around since we need to distinguish between collections making used of reified types from their older types.

==Conclusion==
Despite their deceptively similar syntax, C++ and Java are two very different languages. Likewise, the original goals, programming models, and under-currents shaping their continued evolution are very different. Not surprisingly, their approaches to support generic programming are very different—"simple and comprehensible" in Java and meticulous and comprehensive in C++.

Java Generics substantially improves type safety, encourages software reuse, and adds some basic support for generic programming. For Java, it is a serious step forward in the area of commercial software development. However, Java Generics in its proposed form does not qualify to be called generics (as in generic programming) as yet.

Although some generic programming concepts are difficult in C++, compared to Java, C++ is well advanced and Java has a lot to catch up with. Consequently, claims of Java Generics being "better than C++ templates" are naive and ungrounded at best.

Nevertheless, both languages have their applications and their devoted users. There is enough room for everyone.

==Reference==
<ol>
<li>http://en.wikipedia.org/wiki/Generic_programming</li>

<li>http://en.wikipedia.org/wiki/Generics_in_Java</li>

<li>http://www.oracle.com/technetwork/articles/javase/generics-136597.html</li>

<li>http://download.oracle.com/javase/tutorial/extra/generics/methods.html</li>

<li>http://www.cplusplus.com/doc/tutorial/templates/</li>

<li>http://en.wikipedia.org/wiki/Template_(programming)</li>

<li>http://www.cs.binghamton.edu/~mike/presentations/java-generics-cs580c-fall-2007.pdf</li>

<li>http://jnb.ociweb.com/jnb/jnbJul2003.html</li>

<li>http://tech.puredanger.com/java7/#reified</li>

<li>http://gafter.blogspot.com/2006/11/reified-generics-for-java.html</li>

<li>http://relation.to/21406.lace</li>

<li>http://beust.com/weblog/2011/07/29/erasure-vs-reification</li>

<li>http://aszt.inf.elte.hu/~gsd/s/cikkek/java/p40-ghosh.pdf</li>

<li>http://drdobbs.com/184401818</li>

</ol>

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-18T00:42:10Z

Kkalker:

==Generic Programming==
Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. This enables writing common set of functions which differ only in the types on which they operate. This reduces duplication. Software entities created using generic programming are known as ''generics'' in [http://en.wikipedia.org/wiki/Ada_(programming_language) Ada], [http://en.wikipedia.org/wiki/Eiffel_(programming_language) Eiffel], [http://en.wikipedia.org/wiki/Java_(programming_language) Java], [http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#], [http://en.wikipedia.org/wiki/F_Sharp_(programming_language) F#], and [http://en.wikipedia.org/wiki/Visual_Basic_.NET Visual Basic .NET]; parametric polymorphism in [http://en.wikipedia.org/wiki/ML_(programming_language) ML], [http://en.wikipedia.org/wiki/Scala_(programming_language Scala] and [http://en.wikipedia.org/wiki/Haskell_(programming_language) Haskell], [http://en.wikipedia.org/wiki/template_(programming) template]s in [http://en.wikipedia.org/wiki/C++ C++].

For example, given various data structures and several algorithms, the brute force way would be implement them for each data structure which would mean that various combinations of implementations will be necessary. Generic programming reduces this effort.


==Generics in Java==
===What are Generics?===
Generics were added to Java programming language as a part of J2SE 5.0 release in 2004. They allow programmers to develop generic and compile safe applications which enables a type or method to operate on objects of various type. This feature is well utilized while implementing [http://en.wikipedia.org/wiki/Java_Collections Java Collections]. The reason why people went into generic programming can be well explained using the below example:
<pre>
List list = new ArrayList();
list.add("name");
Integer num = (Integer)list.get(0);
</pre>
In this example, we insert a <code>String</code> into an <code>ArrayList</code> and retrieve element by typecasting with Integer wrapper class. This throws a runtime exception because of Illegal class cast. But if we use generics, runtime exceptions can be avoided and the compiler will be able to catch such issues which in turn help a programmer to build a bug free code. So if we convert the above code to use generic then it would look like this:
<pre>
List<String> list = new ArrayList<String>();
list.add("name");
Integer num = list.get(0); //line 1
</pre>
Here at line 1 the compiler throws an error because the compiler on seeing the declaration of ArrayList will be expecting the list to have just <code>String</code> and thereby the return type of <code>get</code> to be <code>String</code>.

===Implementing Generics:===
Java provides a feature which helps one to implement your own generic types and this will help to build more sophisticated and runtime error free applications. Consider the below example:
<code>
interface List<N> {
void add(N i);
Iterator<N> iterator();
}
interface Iterator<N> {
N next();
boolean hasNext();
}
class LinkedList<N> implements List<N> {
//Business Logic
}
</code>
So here, <code>N</code> can be replaced with any primitive data types or wrapper classes in the business logic. But we need to make sure that placeholders to be replaced with valid subtypes of Object. Generics implementation is not restricted for classes or interfaces, we can have for static/non static methods and constructors.

Example for generic methods:

<pre>
<T> void fromArrayToCollection(T[] a, Collection<T> c) {
for (T o : a) {
c.add(o); // Correct
}
}
</pre>
===Pros and Cons===
Pros:
<ol>
<li>Reduces the number of casts in the program, which in turn reduces the number of potential bugs in the program.</li>
<li>Improves code clarity and maintenance.</li>
</ol>
Cons:
<ol>
<li>Parameter type information is not available at run time.</li>
<li>The automatically generated casts may fail when interoperating with ill-behaved legacy code.</li>
</ol>

==Templates in C++==
===What are templates?===
Templates are functions that can operate with generic types which means that the functionality can be adapted for more than one type of data without repeating the entire code for each type.

===Overview===
Templates can be either function templates or class templates.
====Function Templates====
These are just like regular functions except that they can have arguments of different types. A single function definition works with different kinds of data types. During compile time, the actual functions are generated once the compiler knows the data type being used. This kind of template does not save any memory.

Example
<pre>
template <typename Type>
Type max(Type a, Type b) {
return a > b ? a : b;
}

#include <iostream>

int main()
{
// This will call max <int> (by argument deduction)
std::cout << max(3, 7) << std::endl;
// This will call max<double> (by argument deduction)
std::cout << max(3.0, 7.0) << std::endl;
// This type is ambiguous, so explicitly instantiate max<double>
std::cout << max<double>(3, 7.0) << std::endl;
return 0;
}
</pre>

====Class Templates====
A class template provides a specification for generating classes based on parameters. A class template is instantiated by passing a given set of types to it as template arguments.

Example
<pre>
template <class T>
class mypair {
T values [2];
public:
mypair (T first, T second)
{
values[0]=first; values[1]=second;
}
};
</pre>

===Features of C++ Templates===
Some of the features of C++ templates are:
<ol>
<li>
Implemented in the compiler.<ol><ul>No runtime overhead</ul><ul>Requires template source to be in headers</ul><ul>Latent typing means template instantiator does no type checking</ul></ol>
</li>
<li>Gloriﬁed macro facility<ol><ul>“Macros done right”/“Macros that look like classes”</ul></ol></li>
<li>
Can use template arguments for both classes and straight function</li>
<li>Template specialization<ol><ul>Speciﬁc implementation of a templated type or method</ul></ol></li>
<li>Pattern matching and text replacement<ol><ul>Declarative model (like [http://en.wikipedia.org/wiki/Prolog Prolog])</ul></ol></li>
</ol>

===Pros and Cons===
Usage of templates have both advantages and disadvantages.

Pros
<ol>
<li>Reduction in code size.</li>
<li>They are type-safe, that is, type-checking is done at compile time.</li>
</ol>

Cons
<ol>
<li>Since all compilers are not good at their support for templates, they may not be very portable.</li>
<li>Compilers generate additional code for each template type, this could lead to huge code if usage of templates is not checked.</li>
<li>Information hiding is not achieved as the code is all exposed in the header.</li>
</ol>

==Templates (C++) versus Generics (Java)==
We can compare templates in C++ versus generics in Java based on the following models of comparison,
1. Translation model - discussion based on the way generic code is translated.
2. Type model - discussion based on implementations in type interference, type aliasing and associated types.
3. Security model - discussion based on security loopholes, if any.
Let's look at these with some examples.

===Translation Model===
====Java====
One of the design reasons behind Java's generics was to provide backward compatibility of legacy Java code. To achieve this, Java implementation has adopted the same representation policy for the raw type and the parametric type. The parametric type Collection<T> can be passed safely where the corresponding raw type Collection is expected. Hence the translation model of Java Generics is based on the “type erasure” model, where the translation erases the generic type parameter, replaces them by the bounding type (Object) and inserts casts to the actual places of usage. In order for method overriding to work correctly, the translation process also adds “bridge methods”, as illustrated in the following example.
<pre>
class C<A> { abstract A id(A x); }
class D extends C<String> { String id(String x) { return x; } }
This will be translated to:
class C { abstract Object id(Object x); }
class D extends C {
String id(String x) { return x; }
// bridge method introduced by the translator to make
// overriding work correctly
Object id(Object x) { return id((String)x); }
}
</pre>

====C++====
The translation model of C++ is based on instantiation – no static type checking is done on the generic code. The compiler generates separate copies of the component (class or function) for each instantiation with a distinct type and the type checking is performed after instantiation at each call site. Type checking of the bound types can only succeed when the input types have satisfied the type requirements of the function template body. It is because of this, that misleading error messages are thrown in by the compiler when a generic component is instantiated with an improper type.

====Comparison====
The C++ model is loss-less in the sense that no type information is lost during runtime, though the implementation of the translation suffers from the drawbacks of the possibility of introducing code bloats and misleading error messages. On the other hand, the Java model emphasizes on retrofitting the raw types with the generic counterparts, but the type-erasure model delegates the generic types to “second class” status compared to the conventional types.

===Type Model===
====Java====
Type requirements can be defined on arguments as a set of formal abstractions – this feature is called constrained genericity. The generic types of the classes have to honor these requirements in order to participate in the valid instantiation. Java Generics use interfaces to represent a concept and employ the mechanism of subtyping to model a concept – any type T modeling a concept C will have to implement the corresponding interface.

<pre>
public interface VertexListGraph<Vertex,
VertexIterator extends Iterator<Vertex>> {
VertexIterator vertices();
int num_vertices();
}
public interface IncidenceGraph<Vertex, Edge,
OutEdgeIterator extends Iterator<Edge>> {
OutEdgeIterator out_edges(Vertex v);
int out_degree(Vertex v);
}
public interface VertexListAndIncidenceGraph<…>
extends VertexListGraph<…>, IncidenceGraph<…> {}
public class adjacency_list
implements VertexListAndIncidenceGraph<Integer,
Simple_edge<Integer>, Iterator<Integer>,
Integer, Iterator<simple_edge<Integer>>,
Integer, Iterator<simple_edge<Integer>>> {
……
}
</pre>

The implements clause makes the adjacency_list a model of Vertex List Graph and Incidence Graph concepts.

====C++====
C++ does not offer any means to constrain the template parameters. However, techniques for checking constraints in C++ have been implemented as a library using the notion of compile time assertions.

====Comparison====
Java Generics come without two of the very important features of generic programming – type aliasing and associated types. C++ templates offer both of them, type aliasing through typedefs and the associated types through the traits mechanism. Though typedef s are not part of
the C++ templates per se, but without them writing generic code often becomes extremely
verbose and error prone.

Java has no type aliasing as seen below:
<pre>
dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex, indirect_cmp<Vertex,
Distance, DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> vis
= new dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex,
indirect_cmp<Vertex, Distance,
DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> (Q, weight, predecessor,
distance, combine, compare, zero);
</pre>

Java has no support for associated types:
<pre>
// breadth_first_search prototype in C++
template <class VertexListGraph, class Buffer, class BFSVisitor,
class ColorMap>
void breadth_first_search
(const VertexListGraph& g,
typename graph_traits<VertexListGraph>::vertex_descriptor s,
Buffer& Q, BFSVisitor vis, ColorMap color)
// breadth_first_search prototype in Java
public static <Vertex,
Edge extends GraphEdge<Vertex>,
VertexIterator extends java.util.Iterator<Vertex>,
OutEdgeIterator extends java.util.Iterator<Edge>,
Vis extends Visitor,
ColorMap extends
ReadWritePropertyMap<Vertex,java.lang.Integer>,
QueueType extends Buffer<Vertex>>
void breadth_first_search(VertexListAndIncidenceGraph<Vertex,
Edge,VertexIterator,OutEdgeIterator> g,
Vertex s, Visitor vis, ColorMap color)
</pre>

===Security Model===
====Java====
Java Generics translation model replaces all generic types by the bound type, Object, thereby removing all type information from the runtime system. This is referred to as the homogeneous model of implementing Generics, since all generic types are mapped to a single supertype.

====C++====
C++ implements the heterogeneous model, where the compiler generates a separate copy of the type for each specific instantiation of the type parameter. Hence a generic container Stack<T> will generate separate concrete classes Stack<int> for integers, Stack<double> for double precision numbers, Stack<string> for string data type. While in Java, Stack<T> will be instantiated as Stack collection class.

<pre>
Class BroadcastList<C extends Channel> {
C channels[];
void add(C c) { … }
void broadcast(String s) {
int I;
for(I = 0; I < channels.length; i++)
channels[i].send(s);
}
……
}
Class EncryptedChannel extends Channel;
Class UnencryptedChannel extends Channel;
BroadcastList<EncryptedChannel> list = ……;
list.add(new EncryptedChannel());
(*)
list.broadcast(“Hello”);
</pre>

====Comparison====

Because of the homogeneous implementation, during instantiation of the generic class BroadCastList, C will not contain the exact type, since the translation of Java Generics will erase C. Hence it becomes vulnerable to a malicious program who can add an unencrypted channel to the list (possibly at position marked by (*)) through hand-written byte codes, which will bypass all compile time checking and the compiler generated run-time checks guaranteeing JDK 1.5 (beta) includes a workaround to prevent this security hole; it has a means of constructing a dynamically typesafe view of a specified collection (Collections.checkedCollection()). This ensures that any attempt to insert an element of incorrect type will result in a ClassCastException. But this approach introduces a counterintuitive programming model specifically to address an existing loophole in the security of the JVM.

In C++, this security loophole does not exist since strict type-checking is employed at the points of instantiation of templates. However, this heterogeneous translation model employed by C++ will not fit with the current security model of the Java virtual machine. The JVM offers two levels of visibility – global level (public) and package level. Hence in some cases it becomes impossible to find out the proper package where the instantiated class will be placed honoring the visibility model of the JVM.
==Evolution of Generics==
Here we take Java programming language as an example to explain evolution of generics. Generics were introduced with Java 1.5. However, before that, the codes were bulky and messy but the results were same. Rather than simply using a List<Integer> or Comparable<String>, developers had to deal with a significant amount of inheritance, casting, and instanceof testing. For example, an ArrayList to store only Integers pre-generics might look like the below snippet:
<pre>
public class IntegerList extends ArrayList{
public boolean add(Object o){
if(o instanceof Integer)
return super.add(o);
return false;
}

public Integer get(int index){
return (Integer)super.get(index);
}
}

</pre>
Generics allows to write more modular and reusable code that is adaptable to various datatypes, yet logically restrictive as well. Currently, generics are implemented using erasure, which means that the generic type information is not available at runtime, which makes some kind of code hard to write. Generics were implemented this way to support backwards compatibility with older non-generic code. Reified generics would make the generic type information available at runtime, which would break legacy non-generic code. Generics are implemented using erasure, in which generic type parameters are simply removed at runtime. That doesn't render generics useless, because you get typechecking at compile-time based on the generic type parameters, and also because the compiler inserts casts in the code based on the type parameters.
===Erasure v/s Reification===

Consider the below example, it won't work because of erasure.

<pre>
public class Test<Key, Val> {
public void test(Key key) {
}

public void test(Val value) {
}
}
</pre>
This would give a name clash error for having same erasure and one way to avoid the error is by renaming the method name but this will not the serve the purpose of overloading. Similarly, the below example would give errors because the JVM is not aware of the type T instead views it just as an Object.
<pre>
public class Test {
public <T> void f() {
T t = new T();
}
}
</pre>
So reified generics have support in the compiler for preserving type information whereas type erased generics don't have and that "remember" the class they were created with during runtime. Below are some of the reasons why Java should have reified generics:
<ol>
<li>Type argument erasure cripples frameworks that works with generic types and this results in horrid workarounds</li>
<li>Reified generics allows Typesafe narrowing. Currently in Java, we first test the type of the object using the instanceof operator, and then attempt to downcast it using a C-style typecast</li>
<li>Interoperability between statically-typed is difficult since few support reified generics.</li>
</ol>

But at the same time reified generics have issues and one of the main concern is incompatible with the current collections. So a test on <code>instanceof List<String></code> would now test that the object is an instance of <code>List</code> but also that its elements are of type <code>String</code>. This requires a lot of work around since we need to distinguish between collections making used of reified types from their older types.

==Reference==
<ol>
<li>http://en.wikipedia.org/wiki/Generic_programming</li>

<li>http://en.wikipedia.org/wiki/Generics_in_Java</li>

<li>http://www.oracle.com/technetwork/articles/javase/generics-136597.html</li>

<li>http://download.oracle.com/javase/tutorial/extra/generics/methods.html</li>

<li>http://www.cplusplus.com/doc/tutorial/templates/</li>

<li>http://en.wikipedia.org/wiki/Template_(programming)</li>

<li>http://www.cs.binghamton.edu/~mike/presentations/java-generics-cs580c-fall-2007.pdf</li>

<li>http://jnb.ociweb.com/jnb/jnbJul2003.html</li>

<li>http://tech.puredanger.com/java7/#reified</li>

<li>http://gafter.blogspot.com/2006/11/reified-generics-for-java.html</li>

<li>http://relation.to/21406.lace</li>

<li>http://beust.com/weblog/2011/07/29/erasure-vs-reification</li>

<li>http://aszt.inf.elte.hu/~gsd/s/cikkek/java/p40-ghosh.pdf</li>

</ol>

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-18T00:41:24Z

Kkalker:

==Generic Programming==
Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. This enables writing common set of functions which differ only in the types on which they operate. This reduces duplication. Software entities created using generic programming are known as ''generics'' in [http://en.wikipedia.org/wiki/Ada_(programming_language) Ada], [http://en.wikipedia.org/wiki/Eiffel_(programming_language) Eiffel], [http://en.wikipedia.org/wiki/Java_(programming_language) Java], [http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#], [http://en.wikipedia.org/wiki/F_Sharp_(programming_language) F#], and [http://en.wikipedia.org/wiki/Visual_Basic_.NET Visual Basic .NET]; parametric polymorphism in [http://en.wikipedia.org/wiki/ML_(programming_language) ML], [http://en.wikipedia.org/wiki/Scala_(programming_language Scala] and [http://en.wikipedia.org/wiki/Haskell_(programming_language) Haskell], [http://en.wikipedia.org/wiki/template_(programming) template]s in [http://en.wikipedia.org/wiki/C++ C++].

For example, given various data structures and several algorithms, the brute force way would be implement them for each data structure which would mean that various combinations of implementations will be necessary. Generic programming reduces this effort.


==Generics in Java==
===What are Generics?===
Generics were added to Java programming language as a part of J2SE 5.0 release in 2004. They allow programmers to develop generic and compile safe applications which enables a type or method to operate on objects of various type. This feature is well utilized while implementing [http://en.wikipedia.org/wiki/Java_Collections Java Collections]. The reason why people went into generic programming can be well explained using the below example:
<pre>
List list = new ArrayList();
list.add("name");
Integer num = (Integer)list.get(0);
</pre>
In this example, we insert a <code>String</code> into an <code>ArrayList</code> and retrieve element by typecasting with Integer wrapper class. This throws a runtime exception because of Illegal class cast. But if we use generics, runtime exceptions can be avoided and the compiler will be able to catch such issues which in turn help a programmer to build a bug free code. So if we convert the above code to use generic then it would look like this:
<pre>
List<String> list = new ArrayList<String>();
list.add("name");
Integer num = list.get(0); //line 1
</pre>
Here at line 1 the compiler throws an error because the compiler on seeing the declaration of ArrayList will be expecting the list to have just <code>String</code> and thereby the return type of <code>get</code> to be <code>String</code>.

===Implementing Generics:===
Java provides a feature which helps one to implement your own generic types and this will help to build more sophisticated and runtime error free applications. Consider the below example:
<code>
interface List<N> {
void add(N i);
Iterator<N> iterator();
}
interface Iterator<N> {
N next();
boolean hasNext();
}
class LinkedList<N> implements List<N> {
//Business Logic
}
</code>
So here, <code>N</code> can be replaced with any primitive data types or wrapper classes in the business logic. But we need to make sure that placeholders to be replaced with valid subtypes of Object. Generics implementation is not restricted for classes or interfaces, we can have for static/non static methods and constructors.

Example for generic methods:

<pre>
<T> void fromArrayToCollection(T[] a, Collection<T> c) {
for (T o : a) {
c.add(o); // Correct
}
}
</pre>
===Pros and Cons===
Pros:
<ol>
<li>Reduces the number of casts in the program, which in turn reduces the number of potential bugs in the program.</li>
<li>Improves code clarity and maintenance.</li>
</ol>
Cons:
<ol>
<li>Parameter type information is not available at run time.</li>
<li>The automatically generated casts may fail when interoperating with ill-behaved legacy code.</li>
</ol>

==Templates in C++==
===What are templates?===
Templates are functions that can operate with generic types which means that the functionality can be adapted for more than one type of data without repeating the entire code for each type.

===Overview===
Templates can be either function templates or class templates.
====Function Templates====
These are just like regular functions except that they can have arguments of different types. A single function definition works with different kinds of data types. During compile time, the actual functions are generated once the compiler knows the data type being used. This kind of template does not save any memory.

Example
<pre>
template <typename Type>
Type max(Type a, Type b) {
return a > b ? a : b;
}

#include <iostream>

int main()
{
// This will call max <int> (by argument deduction)
std::cout << max(3, 7) << std::endl;
// This will call max<double> (by argument deduction)
std::cout << max(3.0, 7.0) << std::endl;
// This type is ambiguous, so explicitly instantiate max<double>
std::cout << max<double>(3, 7.0) << std::endl;
return 0;
}
</pre>

====Class Templates====
A class template provides a specification for generating classes based on parameters. A class template is instantiated by passing a given set of types to it as template arguments.

Example
<pre>
template <class T>
class mypair {
T values [2];
public:
mypair (T first, T second)
{
values[0]=first; values[1]=second;
}
};
</pre>

===Features of C++ Templates===
Some of the features of C++ templates are:
<ol>
<li>
Implemented in the compiler.<ol><ul>No runtime overhead</ul><ul>Requires template source to be in headers</ul><ul>Latent typing means template instantiator does no type checking</ul></ol>
</li>
<li>Gloriﬁed macro facility<ol><ul>“Macros done right”/“Macros that look like classes”</ul></ol></li>
<li>
Can use template arguments for both classes and straight function</li>
<li>Template specialization<ol><ul>Speciﬁc implementation of a templated type or method</ul></ol></li>
<li>Pattern matching and text replacement<ol><ul>Declarative model (like [http://en.wikipedia.org/wiki/Prolog Prolog])</ul></ol></li>
</ol>

===Pros and Cons===
Usage of templates have both advantages and disadvantages.

Pros
<ol>
<li>Reduction in code size.</li>
<li>They are type-safe, that is, type-checking is done at compile time.</li>
</ol>

Cons
<ol>
<li>Since all compilers are not good at their support for templates, they may not be very portable.</li>
<li>Compilers generate additional code for each template type, this could lead to huge code if usage of templates is not checked.</li>
<li>Information hiding is not achieved as the code is all exposed in the header.</li>
</ol>

==Templates (C++) versus Generics (Java)==
We can compare templates in C++ versus generics in Java based on the following models of comparison,
1. Translation model - discussion based on the way generic code is translated.
2. Type model - discussion based on implementations in type interference, type aliasing and associated types.
3. Security model - discussion based on security loopholes, if any.
Let's look at these with some examples.

===Translation Model===
====Java====
One of the design reasons behind Java's generics was to provide backward compatibility of legacy Java code. To achieve this, Java implementation has adopted the same representation policy for the raw type and the parametric type. The parametric type Collection<T> can be passed safely where the corresponding raw type Collection is expected. Hence the translation model of Java Generics is based on the “type erasure” model, where the translation erases the generic type parameter, replaces them by the bounding type (Object) and inserts casts to the actual places of usage. In order for method overriding to work correctly, the translation process also adds “bridge methods”, as illustrated in the following example.
<pre>
class C<A> { abstract A id(A x); }
class D extends C<String> { String id(String x) { return x; } }
This will be translated to:
class C { abstract Object id(Object x); }
class D extends C {
String id(String x) { return x; }
// bridge method introduced by the translator to make
// overriding work correctly
Object id(Object x) { return id((String)x); }
}
</pre>

====C++====
The translation model of C++ is based on instantiation – no static type checking is done on the generic code. The compiler generates separate copies of the component (class or function) for each instantiation with a distinct type and the type checking is performed after instantiation at each call site. Type checking of the bound types can only succeed when the input types have satisfied the type requirements of the function template body. It is because of this, that misleading error messages are thrown in by the compiler when a generic component is instantiated with an improper type.

====Comparison====
The C++ model is loss-less in the sense that no type information is lost during runtime, though the implementation of the translation suffers from the drawbacks of the possibility of introducing code bloats and misleading error messages. On the other hand, the Java model emphasizes on retrofitting the raw types with the generic counterparts, but the type-erasure model delegates the generic types to “second class” status compared to the conventional types.

===Type Model===
====Java====
Type requirements can be defined on arguments as a set of formal abstractions – this feature is called constrained genericity. The generic types of the classes have to honor these requirements in order to participate in the valid instantiation. Java Generics use interfaces to represent a concept and employ the mechanism of subtyping to model a concept – any type T modeling a concept C will have to implement the corresponding interface.

<pre>
public interface VertexListGraph<Vertex,
VertexIterator extends Iterator<Vertex>> {
VertexIterator vertices();
int num_vertices();
}
public interface IncidenceGraph<Vertex, Edge,
OutEdgeIterator extends Iterator<Edge>> {
OutEdgeIterator out_edges(Vertex v);
int out_degree(Vertex v);
}
public interface VertexListAndIncidenceGraph<…>
extends VertexListGraph<…>, IncidenceGraph<…> {}
public class adjacency_list
implements VertexListAndIncidenceGraph<Integer,
Simple_edge<Integer>, Iterator<Integer>,
Integer, Iterator<simple_edge<Integer>>,
Integer, Iterator<simple_edge<Integer>>> {
……
}
</pre>

The implements clause makes the adjacency_list a model of Vertex List Graph and Incidence Graph concepts.

====C++====
C++ does not offer any means to constrain the template parameters. However, techniques for checking constraints in C++ have been implemented as a library using the notion of compile time assertions.

====Comparison====Java Generics come without two of the very important features of generic programming – type aliasing and associated types. C++ templates offer both of them, type aliasing through typedefs and the associated types through the traits mechanism. Though typedef s are not part of
the C++ templates per se, but without them writing generic code often becomes extremely
verbose and error prone.

Java has no type aliasing as seen below:
<pre>
dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex, indirect_cmp<Vertex,
Distance, DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> vis
= new dijkstra_visitor<VertexListAndIncidenceGraph<Vertex,
Edge,
VertexIterator,
OutEdgeIterator>,
mutable_queue<Vertex,
indirect_cmp<Vertex, Distance,
DistanceMap, DistanceCompare>>,
WeightMap,
PredecessorMap,
DistanceMap,
DistanceCombine,
DistanceCompare,
Vertex,
Edge,
Distance> (Q, weight, predecessor,
distance, combine, compare, zero);
</pre>

Java has no support for associated types:
<pre>
// breadth_first_search prototype in C++
template <class VertexListGraph, class Buffer, class BFSVisitor,
class ColorMap>
void breadth_first_search
(const VertexListGraph& g,
typename graph_traits<VertexListGraph>::vertex_descriptor s,
Buffer& Q, BFSVisitor vis, ColorMap color)
// breadth_first_search prototype in Java
public static <Vertex,
Edge extends GraphEdge<Vertex>,
VertexIterator extends java.util.Iterator<Vertex>,
OutEdgeIterator extends java.util.Iterator<Edge>,
Vis extends Visitor,
ColorMap extends
ReadWritePropertyMap<Vertex,java.lang.Integer>,
QueueType extends Buffer<Vertex>>
void breadth_first_search(VertexListAndIncidenceGraph<Vertex,
Edge,VertexIterator,OutEdgeIterator> g,
Vertex s, Visitor vis, ColorMap color)
</pre>

===Security Model===
====Java====
Java Generics translation model replaces all generic types by the bound type, Object, thereby removing all type information from the runtime system. This is referred to as the homogeneous model of implementing Generics, since all generic types are mapped to a single supertype.

====C++====
C++ implements the heterogeneous model, where the compiler generates a separate copy of the type for each specific instantiation of the type parameter. Hence a generic container Stack<T> will generate separate concrete classes Stack<int> for integers, Stack<double> for double precision numbers, Stack<string> for string data type. While in Java, Stack<T> will be instantiated as Stack collection class.

<pre>
Class BroadcastList<C extends Channel> {
C channels[];
void add(C c) { … }
void broadcast(String s) {
int I;
for(I = 0; I < channels.length; i++)
channels[i].send(s);
}
……
}
Class EncryptedChannel extends Channel;
Class UnencryptedChannel extends Channel;
BroadcastList<EncryptedChannel> list = ……;
list.add(new EncryptedChannel());
(*)
list.broadcast(“Hello”);
</pre>

====Comparison====

Because of the homogeneous implementation, during instantiation of the generic class BroadCastList, C will not contain the exact type, since the translation of Java Generics will erase C. Hence it becomes vulnerable to a malicious program who can add an unencrypted channel to the list (possibly at position marked by (*)) through hand-written byte codes, which will bypass all compile time checking and the compiler generated run-time checks guaranteeing JDK 1.5 (beta) includes a workaround to prevent this security hole; it has a means of constructing a dynamically typesafe view of a specified collection (Collections.checkedCollection()). This ensures that any attempt to insert an element of incorrect type will result in a ClassCastException. But this approach introduces a counterintuitive programming model specifically to address an existing loophole in the security of the JVM.

In C++, this security loophole does not exist since strict type-checking is employed at the points of instantiation of templates. However, this heterogeneous translation model employed by C++ will not fit with the current security model of the Java virtual machine. The JVM offers two levels of visibility – global level (public) and package level. Hence in some cases it becomes impossible to find out the proper package where the instantiated class will be placed honoring the visibility model of the JVM.
==Evolution of Generics==
Here we take Java programming language as an example to explain evolution of generics. Generics were introduced with Java 1.5. However, before that, the codes were bulky and messy but the results were same. Rather than simply using a List<Integer> or Comparable<String>, developers had to deal with a significant amount of inheritance, casting, and instanceof testing. For example, an ArrayList to store only Integers pre-generics might look like the below snippet:
<pre>
public class IntegerList extends ArrayList{
public boolean add(Object o){
if(o instanceof Integer)
return super.add(o);
return false;
}

public Integer get(int index){
return (Integer)super.get(index);
}
}

</pre>
Generics allows to write more modular and reusable code that is adaptable to various datatypes, yet logically restrictive as well. Currently, generics are implemented using erasure, which means that the generic type information is not available at runtime, which makes some kind of code hard to write. Generics were implemented this way to support backwards compatibility with older non-generic code. Reified generics would make the generic type information available at runtime, which would break legacy non-generic code. Generics are implemented using erasure, in which generic type parameters are simply removed at runtime. That doesn't render generics useless, because you get typechecking at compile-time based on the generic type parameters, and also because the compiler inserts casts in the code based on the type parameters.
===Erasure v/s Reification===

Consider the below example, it won't work because of erasure.

<pre>
public class Test<Key, Val> {
public void test(Key key) {
}

public void test(Val value) {
}
}
</pre>
This would give a name clash error for having same erasure and one way to avoid the error is by renaming the method name but this will not the serve the purpose of overloading. Similarly, the below example would give errors because the JVM is not aware of the type T instead views it just as an Object.
<pre>
public class Test {
public <T> void f() {
T t = new T();
}
}
</pre>
So reified generics have support in the compiler for preserving type information whereas type erased generics don't have and that "remember" the class they were created with during runtime. Below are some of the reasons why Java should have reified generics:
<ol>
<li>Type argument erasure cripples frameworks that works with generic types and this results in horrid workarounds</li>
<li>Reified generics allows Typesafe narrowing. Currently in Java, we first test the type of the object using the instanceof operator, and then attempt to downcast it using a C-style typecast</li>
<li>Interoperability between statically-typed is difficult since few support reified generics.</li>
</ol>

But at the same time reified generics have issues and one of the main concern is incompatible with the current collections. So a test on <code>instanceof List<String></code> would now test that the object is an instance of <code>List</code> but also that its elements are of type <code>String</code>. This requires a lot of work around since we need to distinguish between collections making used of reified types from their older types.

==Reference==
<ol>
<li>http://en.wikipedia.org/wiki/Generic_programming</li>

<li>http://en.wikipedia.org/wiki/Generics_in_Java</li>

<li>http://www.oracle.com/technetwork/articles/javase/generics-136597.html</li>

<li>http://download.oracle.com/javase/tutorial/extra/generics/methods.html</li>

<li>http://www.cplusplus.com/doc/tutorial/templates/</li>

<li>http://en.wikipedia.org/wiki/Template_(programming)</li>

<li>http://www.cs.binghamton.edu/~mike/presentations/java-generics-cs580c-fall-2007.pdf</li>

<li>http://jnb.ociweb.com/jnb/jnbJul2003.html</li>

<li>http://tech.puredanger.com/java7/#reified</li>

<li>http://gafter.blogspot.com/2006/11/reified-generics-for-java.html</li>

<li>http://relation.to/21406.lace</li>

<li>http://beust.com/weblog/2011/07/29/erasure-vs-reification</li>

<li>http://aszt.inf.elte.hu/~gsd/s/cikkek/java/p40-ghosh.pdf</li>

</ol>

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-18T00:28:10Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-18T00:23:55Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-17T11:26:36Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:54:53Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:54:25Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:47:59Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:46:34Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:33:39Z

Kkalker:

CSC/ECE 517 Fall 2011/ch6 6c sj

2011-11-14T03:30:54Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-26T02:52:40Z

Kkalker:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. An object-oriented program may be viewed as a collection of interacting [http://en.wikipedia.org/wiki/Object_(computer_science)/ objects], as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. 

Objects form the basis of OOP. Every Object wraps the data within a set of functions which helps to handle different appropriately. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in [http://en.wikipedia.org/wiki/Attribute_(computing)/ attributes] and exposes its behavior through [http://en.wikipedia.org/wiki/Method_(computer_programming)/ methods]. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. [http://en.wikipedia.org/wiki/Mutator_method/ Getters and Setters] provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below
<table border = 1>
{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

</table>

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)/ data encapsulation].</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder [http://en.wikipedia.org/wiki/Abstraction_(computer_science)/ data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-26T02:08:13Z

Kkalker:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. 

Objects form the basis of OOP. Every Object wraps the data within a set of functions which helps to handle different appropriately. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below
<table border = 1>
{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

</table>

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-25T17:11:15Z

Kkalker:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1/ Why getters and setters are evil?]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
<li>[http://lua-users.org/wiki/SimpleLuaClasses/ Lua - Object oriented scripting]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-25T17:05:05Z

Kkalker:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages ==
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
<li>[http://lua-users.org/wiki/SimpleLuaClasses/ Lua - Object oriented scripting]</li>
</ol>

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-25T17:04:24Z

Kkalker:

Common Attribute/Member Syntax 

Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world i.e it's modeled around data rather than logic. Objects form the basis of OOP. Let us now look at objects, their manipulation and the ways to do so.

== Objects - Attributes and Methods ==
<table>
<tr>
<td>
Similar to real world objects, software objects also consist of state and related behavior. An object stores it's state in attributes and exposes its behavior through methods. Let's look at the pseudo code for a bicycle object.
<pre>
CLASS Bicycle
ATTRIBUTES:
speed: NUMBER
gear: NUMBER
pedal_cadence: NUMBER
METHODS:
ride(speed)
changeGear(gear)
changeCadence(pedal_cadence)
</pre>
</td>
<td>[[File:concepts-object.gif]]</td>
</tr>
</table>
In the above pseudo code, the attributes define the object and the methods provide a way of achieving the desired functionality from that object. The methods use the attributes to manipulate the object and achieve the functionality. From this we can observe that this manipulation is the very essence of programming using objects. Therefore the access of attributes and way of defining method calls very important in OOP.

== Method call / Instance Variable reference Syntax ==
A running debate in O-O languages is whether method calls and instance-variable references should have the same syntax. Different programming languages implement this in different ways. Let's look at them by examples.

=== Same Syntax ===
Languages like Ruby use the same syntax for method calls and variable references. There is no distinction between these. We can see this in the example below:
<pre>
class Song
def duration=(newDuration)
@duration = newDuration
end
end
aSong = Song.new("Bicylops", "Fleck", 260)
aSong.duration » 260
aSong.duration = 257 # set attribute with updated value
aSong.duration » 257
</pre>

This makes it simpler for the programmer to code. Also, it presents uniformity in the code.

=== Differing Syntax ===
Languages like Java employ different syntax for method calls and variable references as seen in this example below:
<pre>
class Song{
int duration;
Song(){}
void setDuration(int dur){
duration = dur;
}
}

Song sng = new Song();
sng.setDuration(260);
System.out.println("Song duration = "+sng.duration);
</pre>

As seen above, a method is always called using parenthesis, within which arguments may be included if required. However, instance variable is accessed directly.

== Getters and Setters and their Advantages
One of the principles of Objected Oriented Design is that an object's implementation should not be exposed to other classes. This is to avoid difficulty in maintenance. Getters and setters provide a way to read or write private data of a class for any kind of manipulation. They also provide for easy maintenance, in that, if any change needs to be made in the way the variable is set, only the setter method needs to be changed rather than looking for it and changing in every place. These methods also improve the code readability and bring about uniformity across the code.

== Comparison of syntax between various Programming Languages ==
The usage syntax of methods, instance variables, getters and setters is in the table below

{|class="wikitable"
|-
!Programming Languages
!Method call
!Fields/Attributes
!Getter / Setter
!Comparison
|-
|ABAP (Advanced Business Application Programming)
|<pre>
CALL METHOD <meth> EXPORTING... <ii> =.<f i>...
IMPORTING... <ei> =.<g i>...
CHANGING ... <ci> =.<f i>...
RECEIVING r = h
EXCEPTIONS... <ei> = rc i...
</pre>
|data field type type
|Same as other methods with the only difference that they start with SET or GET
|Syntax is different for method calls and instance-variable reference
|-
|C++
|ObjectName.MethodName(parameters)
|Same as methods. Example below:
<pre>
int getHealth() const { return health; }
void setHealth(int h) { health = h; }
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|C#
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|They are just like methods. Example below:
<pre>
public string GetName()
{
return m_name;
}

public void SetName(string name)
{
m_name = name;
}
</pre>
|Different syntax is used to call methods and instance-variable references
|-
|Java
|ObjectName.MethodName(parameters) [Eg: x.method()]
|ObjectName.Attribute [Eg: x.field]
|They are nothing but method calls
|Different syntax is used to call methods and instance-variable references
|-
|D
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|No need for getters and setters. It can be directly accessed.
<pre>
import std.stdio;

class Car
{
float speed = 1.0;
}

void main(){
auto my_car = new Car();
my_car.speed = 2.5;
writefln(my_car.speed);
}
</pre>
|Syntax used for method calls and variable references is different
|-
|Objective C
|output = [object methodWithOutput]
|ObjectName->Attribute
|An example of getter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}

- (NSString*) caption;
- (NSString*) photographer;

@end
</pre>
An example of setter is below
<pre>
#import <Cocoa/Cocoa.h>

@interface Photo : NSObject {
NSString* caption;
NSString* photographer;
}
- (NSString*) caption;
- (NSString*) photographer;

- (void) setCaption: (NSString*)input;
- (void) setPhotographer: (NSString*)input;

@end
</pre>
|Syntax used for method calls and variable references is different
|-
|Python
|ObjectName.MethodName(parameters)
|ObjectName.Attribute
|Pythonic way of implementing getters and setters is to using public members and turning them into properties when needed
|Syntax used for method calls and variable references is sometimes the same and different at times (when there are arguments)
|-
|Javascript
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
var lost = {
loc : "Island",
get location () {
return this.loc;
},
set location(val) {
this.loc = val;
}
};
lost.location = "Another island";
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|PHP
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|N/A. Attributes can be accessed directly.
|Syntax is different for method calls and instance-variable reference
|-
|VB.NET
|ObjectName.MethodName(Parameters);
ObjectNmae.MethodName
|ObjectName.Attribute
|<pre>
Public Property myProperty As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
somethingElse = value
End Set
End Property
</pre>
|Syntax may be same for method calls and instance-variable reference
|-
|Ruby
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>
class Message
attr_reader :message
def message=(m)
@message = m.dup
end
end

class Message
attr_writer :message
def message
@message.encode!("UTF-8")
end
end
</pre>
|Syntax is same for method calls and instance-variable reference
|-
|Lua
|ObjectName.MethodName(Parameters);
|ObjectName.Attribute
|<pre>
local index = getters and
function(self, key)
-- read from getter, else from fallback
local func = getters[key]
if func then return func(self) else return fallback[key] end
end
or fallback -- default to fast property reads through table
local newindex = setters and
function(self, key, value)
-- write to setter, else to proxy
local func = setters[key]
if func then func(self, value)
else rawset(self, key, value) end
end
</pre>
|Syntax is different for method calls and instance-variable reference
|-
|Perl
|$ObjectName->MethodName(Parameters);
|$ObjectName->Attribute
|<pre>

BEGIN {
my @attr = qw(author title number);
no strict 'refs';
for my $a (@attr){
*{__PACKAGE__ . "::get_$a"} = sub { $_[0]->{$a} };
*{__PACKAGE__ . "::set_$a"} = sub { $_[0]->{$a} = $_[1] };
}
}
</pre>
|Syntax is different for method calls and instance-variable reference
|}

== Conclusion ==

Having getters and setters in the implementation has its own advantages and disadvantages. The advantages are that
<ol>
<li>They provide data encapsulation.</li>
<li>They improve the code readability.</li>
<li>Changes can be made only to the implementation without making changes to the code that uses the object.</li>
</ol>
Using getters and setters also has a disadvantage. They largely provide access to implementation details. But this could hinder data abstraction, i.e. hiding the object's implementation of a message handler. Consider a getter function that returns a number. Wherever this method is called, the variable which holds the return value must match the return type of this function. Now if we change they way this method is implemented by changing the return type, then there could be trouble.

Therefore it is important to design such that there is minimal data movement thereby minimizing possible errors.
Using the same syntax for method calls and instance variable references have some advantages and disadvantages. One could argue that having the same syntax makes it simpler for the programmer. It makes the code lighter in terms of lines of code, thus avoiding bulky code. However, including distinct ways for using methods and variables enhances readability by enabling better understanding. This is possible because the manipulation is visible whereas if the syntax were the same(i.e. compact), the one reading has no idea about what is happening "under the hood".

== References ==
<ol>
<li>[http://help.sap.com/saphelp_nw04/helpdata/en/08/d27c03b81011d194f60000e8353423/content.htm/ Declaring and Calling Methods]</li>
<li>[http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)/ Comparison of Programming Languages]</li>
<li>[http://forums.sdn.sap.com/thread.jspa?threadID=529448&tstart=6135/ Setters and Getters in ABAP]</li>
<li>[http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php/ Getters and Setters]</li>
<li>[http://cocoadevcentral.com/d/learn_objectivec/ Objective C]</li>
<li>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html/ Ruby Classes- Objects]</li>
<li>[http://www.vbtutor.in/getting-started-with-visual-basic-net/object-oriented-programming-in-vbnet/ VB.Net Object oriented programming]</li>
<li>[https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript/ Javascript - Functions/Objects]</li>
<li>[http://www.massassi.com/php/articles/classes/ PHP - Objects]</li>
<li>[http://www.tutorialspoint.com/perl/perl_oo_perl.htm/ Perl - Objects]</li>
<li>[http://lua-users.org/wiki/SimpleLuaClasses/ Lua - Object oriented scripting]</li>
</ol>

Trial

2011-09-09T02:58:16Z

Kkalker:

[[File:concepts.gif]]

Trial

2011-09-09T02:58:05Z

Kkalker: Created page with "File:concepts-object.gif"

[[File:concepts-object.gif]]

CSC/ECE 517 Fall 2011

2011-09-09T02:57:45Z

Kkalker:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2010/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:36:34Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:24:03Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:22:07Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T03:13:20Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:40:09Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:32:08Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:31:18Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:29:02Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:27:18Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:21:52Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-08T00:14:45Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:52:26Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:34:10Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:26:12Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:24:58Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:18:39Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T23:18:03Z

Kkalker:

File:Concepts-object.gif

2011-09-07T22:50:21Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T22:49:38Z

Kkalker:

Common Attribute/Member Syntax 
[[File:concepts-object.gif]]
Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world.

== Objects ==

<pre>

Rambo

</pre>

=== Attributes ===

=== Methods ===

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T22:47:05Z

Kkalker:

Common Attribute/Member Syntax 
[[File:http://download.oracle.com/javase/tutorial/figures/java/concepts-object.gif]]
Different object oriented programming languages include different ways of accessing the member variables and methods. This page discusses the various usages and their advantages and disadvantages.

== Introduction ==
The purpose of [http://en.wikipedia.org/wiki/Object-oriented_programming/ Object Oriented Programming] is to make programs model things the way people think or deal with the world.

== Objects ==

<pre>

Rambo

</pre>

=== Attributes ===

=== Methods ===

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T20:38:58Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T20:37:51Z

Kkalker:

CSC/ECE 517 Fall 2011/ch1 1h ps

2011-09-07T00:37:51Z

Kkalker: Created page with "'''Common Attribute/Member Syntax''' ==Team== 1. Smitha Kalkere Sudarshan 2. Pradeep Kumar Ramaswamy"

'''Common Attribute/Member Syntax'''
==Team==
1. Smitha Kalkere Sudarshan
2. Pradeep Kumar Ramaswamy

CSC/ECE 517 Fall 2011

2011-09-05T22:34:50Z

Kkalker:

*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2010/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

CSC/ECE 517 Fall 2011

2011-09-05T19:30:51Z

Kkalker: a new page

*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2010/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1g ps]]