Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:39:25Z

Eeled: /* References */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer]

It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().[http://programming-scala.labs.oreilly.com/ch06.html]

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>
This outputs:
<pre>
2
4
</pre>

===PHP===
<pre>
class Foo{
private $x;

function __construct($x){
$this->x = $x;
}

function x(){
return $this->x;
}

function squared_x(){
return $this->x * $this->x;
}
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();
</pre>
This outputs:
<pre>
2
4
</pre>

''Note that these examples were taken from wikipeda''[http://en.wikipedia.org/wiki/Uniform_access_principle]

==References==
#[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]
#[http://en.wikipedia.org/wiki/Uniform_access_principle Uniform Access Principal]
#[http://dotnetperls.com/count-array .Net Perls]
#[http://www.eiffel.com/general/column/2005/Sept_October.html Eiffel World]
#[http://programming-scala.labs.oreilly.com/ch06.html OO Programing in Scala]

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:38:19Z

Eeled: /* Uniform Access Principle */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer]

It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().[http://programming-scala.labs.oreilly.com/ch06.html]

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>
This outputs:
<pre>
2
4
</pre>

===PHP===
<pre>
class Foo{
private $x;

function __construct($x){
$this->x = $x;
}

function x(){
return $this->x;
}

function squared_x(){
return $this->x * $this->x;
}
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();
</pre>
This outputs:
<pre>
2
4
</pre>

''Note that these examples were taken from wikipeda''[http://en.wikipedia.org/wiki/Uniform_access_principle]

==References==
#[Bertrand Meyer http://en.wikipedia.org/wiki/Bertrand_Meyer]
#[Uniform Access Principal http://en.wikipedia.org/wiki/Uniform_access_principle]
#[.Net Perls http://dotnetperls.com/count-array]
#[Eiffel World http://www.eiffel.com/general/column/2005/Sept_October.html]
#[OO Programing in Scala http://programming-scala.labs.oreilly.com/ch06.html]

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:34:04Z

Eeled: /* Origin of the Uniform Access Principle */

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:33:33Z

Eeled: /* Language Restrictions */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().[http://programming-scala.labs.oreilly.com/ch06.html]

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>
This outputs:
<pre>
2
4
</pre>

===PHP===
<pre>
class Foo{
private $x;

function __construct($x){
$this->x = $x;
}

function x(){
return $this->x;
}

function squared_x(){
return $this->x * $this->x;
}
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();
</pre>
This outputs:
<pre>
2
4
</pre>

''Note that these examples were taken from wikipeda''[http://en.wikipedia.org/wiki/Uniform_access_principle]

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:32:47Z

Eeled: /* Code Examples */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>
This outputs:
<pre>
2
4
</pre>

===PHP===
<pre>
class Foo{
private $x;

function __construct($x){
$this->x = $x;
}

function x(){
return $this->x;
}

function squared_x(){
return $this->x * $this->x;
}
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();
</pre>
This outputs:
<pre>
2
4
</pre>

''Note that these examples were taken from wikipeda''[http://en.wikipedia.org/wiki/Uniform_access_principle]

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:31:59Z

Eeled: /* Code Examples */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>
This outputs:
<pre>
2
4
</pre>

===PHP===
<pre>
class Foo{
private $x;

function __construct($x){
$this->x = $x;
}

function x(){
return $this->x;
}

function squared_x(){
return $this->x * $this->x;
}
}

$y = new Foo(2);
echo $y->x();
echo $y->squared_x();
</pre>
This outputs:
<pre>
2
4
</pre>

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:30:50Z

Eeled: /* Code Examples */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</pre>

This outputs:
<pre>
2
4
</pre>

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:30:08Z

Eeled: /* Code Examples */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===
<pre>
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end
</pre>

y = Foo.new(2)
puts y.x
puts y.squared_x

This outputs:
<pre>
2
4
</pre>

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:28:56Z

Eeled: /* Ruby */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===

class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x

This outputs:
<pre>
2
4
</pre>

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:28:23Z

Eeled: /* Uniform Access Principle */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

===Ruby===

<source lang="ruby">
class Foo
attr_reader :x
def initialize(x)
@x = x
end
def squared_x
return @x * @x
end
end

y = Foo.new(2)
puts y.x
puts y.squared_x
</source>
This outputs:
<pre>
2
4
</pre>

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:26:38Z

Eeled: /* Uniform Access Principle */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:25:54Z

Eeled: /* Uniform Access Principle */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Setter methods are much easier to implement than setting a field that could be an attribute or could be associated with a method. Because of this inherent ambiguity, the language will probably not be able to determine how to handle a field being set on its own. The only good and consistent solution is to enforce the rule that the designer must specify how to handle an assignment for each method that is written. This can be burdensome on the original designer.[http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T02:18:09Z

Eeled: /* Uniform Access Principle */

=Uniform Access Principle=

The '''Uniform Access Principle''' states that any attribute of a module (usually a class) should be accessed with the same syntax, regardless of the nature of the data. Simply put, when a consumer reads or writes a value, they should not know (or care) weather they accessing a variable or invoking a method. Thus, no matter how the module internally handles the data, externally the information is always accessed uniformly.

==Origin of the Uniform Access Principle==
The Uniform Access Principle was created by the French engineer Bertrand Meyer. Meyer is known to be a strong proponent of object oriented programming, and in fact was one of the earliest and most outspoken champions of OO. His book ''Object-Oriented Software Construction'', first published in 1988, is considered to be a foundational publication of the object oriented programming movement.[http://en.wikipedia.org/wiki/Bertrand_Meyer] It was in this book that he put forth the uniform access principal by stating "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."[http://en.wikipedia.org/wiki/Uniform_access_principle]

==Advantages of the Uniform Access Principle==

There are many advantages associated with using the Uniform Access Principal when writing software.

===Reading Properties===
Reading values (or getting) from an object is a syntactic cinch in code that uses the Uniform Access Principal. Just refer to the field that holds the relevant data and the information is accessible. This is a very simple way of interfacing with an external class.

===Ease of Understanding===
Accessing data from a class can be confusing if the user does not know how the data is stored. For example, in C# it is often hard to remember how to access the number of items in a collection - is it collection.Count or collection.Count()? It turns out that the syntax is collection.Count for a generic collection, but it is collection.Count() for an enumerable collection.[http://dotnetperls.com/count-array]

This difference in syntax can be confusing to a user trying to access the data within an otherwise opaque object. If this data was uniformly accessible, it would be much less confusing.

===Convenience of Interface===
Similarly, it is convenient for a user to not have to remember details of an objects implementation to access data within the object. If the Uniform Access Principal is exercised, the programmer does not need to keep track of which values are computed in methods and which are just attributes. A user can simply access the data named what they are interested in.

===Maintainability of Interface===
Utilizing the Uniform Access Principal also aids in maintaining (reads 'not breaking') existing interfaces. For example, lets say there was a BankAccount class. That BankAccount class has an attribute called "Balance", which simply contains the balance value for that account. But later, the policy of the BankAccount changes, such that the balance is not a stored value, but must be computed by adding multiple values together.

In implementations that do not support the Uniform Access Principal, the accessing of that data could go from bankAcnt.Balance to bankAcnt.GetBalance(), thus 'breaking' any code that was depending on the balance property.

However, with an implementation that utilizes the Uniform Access Principal, this change will not be a problem. Be it a stored value, or a value computed in a method call, the accessing of this data could always be done with the same syntax.

==Disadvantages of the Uniform Access Principle==
Although it is a long-held tenet of good object oriented design, there can be some drawbacks to using the Uniform Access Principal.

===Writing Properties===
Although the Uniform Access Principle makes reading data easy, writing values (or setting) can be tricky. Because the language will probably not be able to determine how to interpret an a [http://www.eiffel.com/general/column/2005/Sept_October.html]

===Performance Issues===
When retrieving data from a class that utilizes the Uniform Access Principal, it could potentially mask or obfuscate a performance hit the user was not anticipating. Consider a scenario where a piece of code needs to find the highest temperature value from a collection of many years worth of readings. A non-uniform access implementation might read something like weather.getHighestTempFromAllReadings(). An implementation using the Uniform Access Principal would likely look more like "weather.HighTemp".

The second option makes it appear that the highest temperature is just a value kept track of in the object, when in fact the data is off in a massive collection that must be searched. The user might be surprised that "weather.HighTemp" takes a long time to return a value. However, to a user invoking "weather.getHighestTempFromAllReadings()" it should be apparent that the method call is busy searching through millions of records and will return a value once it is found.

===Class Maintenance===
Maintaining code using the Uniform Access Principle might be difficult, especially if a different programmer originally designed the module. It would be unclear to the maintainer which values are computed and which are just stored. Whereas, in implementations where methods and attributes are clearly different, it would be easier to understand what was what.

===Language Restrictions===
It is actually impossible to utilize the Uniform Access Principle in some languages. For example, in Java fields and methods are kept in different namespaces. This means that fields and methods can have the same names. And because they are not restricted by these names, a field named myValue is completely independent from a method named myValue().

==Code Examples==

==References==

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T01:52:47Z

Eeled: /* Uniform Access Principle */

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T01:37:07Z

Eeled: /* Uniform Access Principle */

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T01:16:39Z

Eeled: /* Uniform Access Principle */

CSC/ECE 517 Fall 2009/wiki3 19 ee

2009-11-19T00:04:33Z

Eeled:

=Uniform Access Principle=

The '''Uniform Access Principle''' states that...

==Origin of the Uniform Access Principle==

==Advantages of the Uniform Access Principle==

===Ease of Understanding===
===Convenience of Interface===
===Maintainability of Interface===

==Disadvantages of the Uniform Access Principle==

===Performance Issues===
===Class Maintenance===
===Language Restrictions===

==Code Examples==

==References==

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T03:05:14Z

Eeled: /* OCaml */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

====Examples====
Basic class for Hello World program

<pre>
class hello_all =
object (self)
val hello = "Hi there"

method greet =
print_string hello

end;;
</pre>
[http://www.ocaml-tutorial.org/objects]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>
[http://www.artima.com/scalazine/articles/steps.html]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]
#[http://www.artima.com/scalazine/articles/steps.html First Steps to Scala]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:55:15Z

Eeled: /* Hybrid Object Oriented Programming Languages */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

====Examples====
<pre>
class hello_all =
object (self)
val hello = "Hi there"

method greet =
print_string hello

end;;
</pre>

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>
[http://www.artima.com/scalazine/articles/steps.html]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]
#[http://www.artima.com/scalazine/articles/steps.html First Steps to Scala]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:32:49Z

Eeled: /* OCaml */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

====Examples====

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>
[http://www.artima.com/scalazine/articles/steps.html]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]
#[http://www.artima.com/scalazine/articles/steps.html First Steps to Scala]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:18:34Z

Eeled: /* References */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>
[http://www.artima.com/scalazine/articles/steps.html]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]
#[http://www.artima.com/scalazine/articles/steps.html First Steps to Scala]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:18:10Z

Eeled: /* Scala */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>
[http://www.artima.com/scalazine/articles/steps.html]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:17:09Z

Eeled: /* Scala */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods
[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>
//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet
</pre>

Example using a trait

<pre>
trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}
</pre>

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T02:14:18Z

Eeled: /* Scala */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Instead of interfaces, Scala uses the idea of "traits" which are like interfaces, but they ''can'' have fully defined methods
[http://www.scala-lang.org/node/25]

====Example====
"Fancy" Hello world:

<pre>

//Note that the arguments to the constructor are just after the class name
class FancyGreeter(greeting: String)
{
def greet() = println(greeting)
}

val g = new FancyGreeter("Salutations, world")
g.greet

</pre>

Using traits

<pre>

trait Introduction{
def intro() = "Hello there"
}

trait Excited extends Introduction {
override def intro() = super.intro() + "!"
}

</pre>

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T01:55:22Z

Eeled:

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax
*For safety of data, Scala is statically typed
*For convenience, Scala does not require the type of a variable to be declared, the Scala compiler can infer the type
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to act as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
[http://www.scala-lang.org/node/25]

====Example====
<pre>
"hello world"
</pre>

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-15T01:45:34Z

Eeled:

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*For safety of data, Scala is statically typed
*Scala is a functional language, in that it allows function passing and nested functions
*But in order to be functional as an OO language, Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins
*Scala aims to allow programmers to leverage the universal compatibility and extensive library support of the java language, while using a compact, flexible and easy to use syntax[http://www.scala-lang.org/node/25]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T03:30:11Z

Eeled: /* References */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala is statically typed to ensure safety
*Scala is a functional language, in that it allows function passing and nested functions
*Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins [http://www.scala-lang.org/node/25]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP Introduction to Object Oriented Programming Concepts]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93# Procedural Programming]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T03:29:08Z

Eeled: /* References */

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala is statically typed to ensure safety
*Scala is a functional language, in that it allows function passing and nested functions
*Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins [http://www.scala-lang.org/node/25]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]
#[http://www.defmacro.org/ramblings/fp.html Functional Programming for the Rest Of Us]
#[http://caml.inria.fr/about/history.html A History of Caml]
#[http://caml.inria.fr/about/index.en.html About OCaml]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733 A Brief History of Scala]
#[http://www.scala-lang.org/node/25 The Scala Programming Language]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T03:26:58Z

Eeled:

=Hybrid Object Oriented Programing Languages=

'''Hybrid Object Oriented Programming Languages''' are object oriented languages that also include one or more additional programing paradigms. Commonly, hybrid object oriented languages include procedural and functional programing features, in addition to being object oriented. Having multiple paradigms embraced in one language adds flexibility to the developer, letting them leverage the most appropriate programing methods, without having to switch languages.

==Programing Paradigms==
Before delving into Hybrid Languages, here is a quick review of the paradigms we will be discussing.

===Object Oriented Programming===
In Object Oriented Programming, code is grouped together into collections called Objects. Objects keep track of data and contain methods relevant to the data of the object. An object is described by a class. In order for an object to be used, it must be instantiated from a class. Objects can utilize other objects to help represent their data in meaningful ways (ie a school object can have many student objects).[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]

===Procedural Programming===
With procedural programming, operations are listed one after another in the order they are to be executed. Procedural programming also incorporates the notion of functions, which are chucks of code that can be called repeatedly, usually to accomplish one specific task. Functions take in data to be processed as arguments and output the result of the computation. However, the output of a function can vary greatly, depending on the state of the program at any given moment.[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]

===Functional Programming===
Functional Programming has strong roots in mathematics and focuses on calculations. Functions are called only to compute data and do not change the state of the program. The output of functions in functional programming depend only on the arguments to the function, with no dependency on the state of the system. Also, all variables are final - that is, once assigned to, they cannot be changed. All these factors make functional programs very reliable and repeatable.[http://www.defmacro.org/ramblings/fp.html]

==Hybrid Object Oriented Programming Languages==
The following Languages use Hybrid Object Oriented Programming Paradigms:

===OCaml===
OCaml was an addition to the Caml programming language, which was itself derived from ML. ML (Meta-Language) was originally developed as a highly functional programming language. It was used to assist with mathematical proofs. Caml was derived from ML to create a flexible programming language and it began to incorporate more procedural programming aspects. Finally, OCaml was implemented, which added object oriented features such as multiple inheritance and module hierarchy management.[http://caml.inria.fr/about/history.html]

====Design Considerations====
*By default, data in OCaml (variables, arrays, ect) are not modifiable, because of its roots in functional programming. However, to allow for more expressive procedural programming, variables are allowed to be declared as modifiable.
*To ensure safety, OCaml is statically typed and type matching is enforced at compile time. This prevents many common run time errors, but does require attention to detail by the programmer. This strong-typing is also true of objects in OCaml. At compile time, OCaml makes sure that no object will receive a message it is not able to understand.
*OCaml allows for the definition of new data types using the concept of a data constructor.[http://caml.inria.fr/about/index.en.html]

===Scala===
Scala was written from the ground up Martin Odersky. It is completely interoperable with Java and naively compiles to Java byte code. Because of this, any Scala program can invoke any Java library, which lets developers leverage a multitude of available Java resources, while working within the Scala language.[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]

====Design Considerations====
*Scala is statically typed to ensure safety
*Scala is a functional language, in that it allows function passing and nested functions
*Scala also embraces the everything-is-an-object paradigm
*Scala allows for multiple inheritance using mixins [http://www.scala-lang.org/node/25]

==References==
#[http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx#OOP]
#[http://knol.google.com/k/chris/procedural-programming/3qdf5q2hz62mx/93#]
#[http://www.defmacro.org/ramblings/fp.html]
#[http://caml.inria.fr/about/history.html]
#[http://caml.inria.fr/about/index.en.html]
#[http://www.artima.com/weblogs/viewpost.jsp?thread=163733]
#[http://www.scala-lang.org/node/25]

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T03:08:54Z

Eeled:

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T02:35:41Z

Eeled:

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T01:06:39Z

Eeled:

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T00:33:49Z

Eeled:

CSC/ECE 517 Fall 2009/wiki2 6 ee

2009-10-10T00:11:15Z

Eeled:

=Hybrid Object Oriented Programing Languages=

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-21T21:00:36Z

Eeled: /* References */

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have become more and more popular for a variety of reasons.

==Definitions==
*'''Version Control''' - A system for managing changes and history for software source code
*'''Branching''' - In a version control system, branching is the idea of making a copy of all or part of the code base and making changes separate from the main line. This allows for developers to develop new features or experiment without "breaking the build" on the main code base
*'''Merging''' - After branching in a version control system, developers might want to reincorporate changes from a branch back into the main code base. This process of re-incorporating new changes is called merging
*'''Repository''' - The location where files under version control are stored. Repositories can take many forms, depending on the particular version control system.

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes [http://en.wikipedia.org/wiki/Branch_%28software%29 branching] and [http://en.wikipedia.org/wiki/Merge_%28revision_control%29 merging] natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a branch[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a change associated with a particular guid, there is no need to incorporate that change.

==List Of Distributed Version Control Systems==
*[http://git-scm.com/ Git]
*[http://bazaar-vcs.org/ Bazaar]
*[http://mercurial.selenic.com/wiki/ Mercurial]
*[http://www.bitkeeper.com/ BitKeeper]

==References==
#[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php Why Distributed ]
#[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Version Control Illustrated]

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-21T20:59:42Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have become more and more popular for a variety of reasons.

==Definitions==
*'''Version Control''' - A system for managing changes and history for software source code
*'''Branching''' - In a version control system, branching is the idea of making a copy of all or part of the code base and making changes separate from the main line. This allows for developers to develop new features or experiment without "breaking the build" on the main code base
*'''Merging''' - After branching in a version control system, developers might want to reincorporate changes from a branch back into the main code base. This process of re-incorporating new changes is called merging
*'''Repository''' - The location where files under version control are stored. Repositories can take many forms, depending on the particular version control system.

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes [http://en.wikipedia.org/wiki/Branch_%28software%29 branching] and [http://en.wikipedia.org/wiki/Merge_%28revision_control%29 merging] natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a branch[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a change associated with a particular guid, there is no need to incorporate that change.

==List Of Distributed Version Control Systems==
*[http://git-scm.com/ Git]
*[http://bazaar-vcs.org/ Bazaar]
*[http://mercurial.selenic.com/wiki/ Mercurial]
*[http://www.bitkeeper.com/ BitKeeper]

==References==
#[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]
#[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]
#

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-21T20:51:39Z

Eeled: /* Definitions */

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-21T20:49:47Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have become more and more popular for a variety of reasons.

==Definitions==
*'''Version Control''' - A system for managing changes and history for software source code
*'''Branching''' - In a version control system, branching is the idea of making a copy of all or part of the code base and making changes separate from the main line. This allows for developers to develop new features or experiment without "breaking the build" on the main code base
*'''Merging''' - After branching in a version control system, developers might want to reincorporate changes from a branch back into the main code base. This process of re-incorporating new changes is called merging

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes [http://en.wikipedia.org/wiki/Branch_%28software%29 branching] and [http://en.wikipedia.org/wiki/Merge_%28revision_control%29 merging] natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a branch[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a change associated with a particular guid, there is no need to incorporate that change.

==List Of Distributed Version Control Systems==
*[http://git-scm.com/ Git]
*[http://bazaar-vcs.org/ Bazaar]
*[http://mercurial.selenic.com/wiki/ Mercurial]
*[http://www.bitkeeper.com/ BitKeeper]

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T05:47:41Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have become more and more popular for a variety of reasons.

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes [http://en.wikipedia.org/wiki/Branch_%28software%29 branching] and [http://en.wikipedia.org/wiki/Merge_%28revision_control%29 merging] natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a branch[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a particular guid, there is no need to incorporate that change.

==List Of Distributed Version Control Systems==
*[http://git-scm.com/ Git]
*[http://bazaar-vcs.org/ Bazaar]
*[http://mercurial.selenic.com/wiki/ Mercurial]
*[http://www.bitkeeper.com/ BitKeeper]

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T05:41:44Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have started to take hold in a big way.

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php]

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes [http://en.wikipedia.org/wiki/Branch_%28software%29 branching] and [http://en.wikipedia.org/wiki/Merge_%28revision_control%29 merging] natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a branch[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a particular guid, there is no need to incorporate that change.

==List Of Distributed Version Control Systems==
*[http://git-scm.com/ Git]
*[http://bazaar-vcs.org/ Bazaar]
*[http://mercurial.selenic.com/wiki/ Mercurial]
*[http://www.bitkeeper.com/ BitKeeper]

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T05:25:52Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed version control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.

Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have started to take hold in a big way.

==Infrastructure==
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
===Repositories===
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.

===Sharing Changes===
When a developer commits a change to their repository, that change set is assigned a [http://en.wikipedia.org/wiki/Globally_Unique_Identifier guid]. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.

==Branching and Merging==
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes branching and merging natural.

===Branching===
Because every developer has their own separate repository, each of these can be viewed as a [http://en.wikipedia.org/wiki/Branch_%28software%29 branch]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.

===Merging===
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a particular guid, there is no need to incorporate that change.

==Distributed Vs Centralized Version Control==

==List Of Distributed Version Control Systems==
Git
Bazaar
Mercurial
BitKeeper

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T04:32:45Z

Eeled:

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T04:29:30Z

Eeled:

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T04:28:40Z

Eeled:

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T04:13:16Z

Eeled:

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T03:47:47Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

'''Distributed Version Control''' is a type of [http://betterexplained.com/articles/a-visual-guide-to-version-control/ revision control] system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorportate external changes, they can "pull" a set of changes into their own repository.
==Distributed Vs Centralized Version Control==
===Infrastructure===
===Branching===
===Publishing===

==Distributed Version Control Systems==

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T03:12:03Z

Eeled:

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T02:50:35Z

Eeled:

=Distributed Version Control Systems=

==Overview of Distributed Version Control==

==Distributed Vs Centralized Version Control==
===Infrastructure===
===Branching===
===Publishing===

==Distributed Version Control Systems==

CSC/ECE 517 Fall 2009/wiki1a 3 ee

2009-09-09T02:17:30Z

Eeled:

Distributed Version Control Systems