CSC/ECE 517 Fall 2010/ch1 4e dj: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Page Stub for Dzoba and Jeremy for Prototype-based programming
=Introduction=
=Introduction=
Prototype based programming is centered around the idea of developing object oriented code by developing functionality at the object level, and then abstracting the code into prototypes. This allows the programmer the ability to develop objects without the overhead of determining class relations, associations, and requirements.
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects.  There are two main ways to do this.  The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different.  The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.[[#References|[1]]]


=Prototypes vs. classes=
=Prototypes vs. Sets=
A class is a definition of an objects behavior and data fieldsThis definition generally does not change throughout the execution of the code.
When defining like behavior, the first method of doing this is by listing all the like components as you define the class.  This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes.  These can be methods, fields, or accessors.  A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods.  These classes are used as an answer to multiple inheritance in languages such as Java.  Interfaces allow a behavior contract to be used to specify how objects interactA using piece of code can use any implementing object that follows the contract.


A prototype is an object that is to be used as a basis for developing another object.  Not only does a prototype contain data, but it also contains behaviors for the object.
However, the second method, prototyping, does not explicitly define any relationships.  Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.


=Creation using each method=
=Creation using each method=
A class can be created through its constructorThis restricts creation to explicit calls to the new method of the class, and prevents changing the objects behavior after the object is instantiated.
When using classes and set based creation, instances are (usually) bound to their defining classes.  This means that when you create a new object, it must match some defined class.  The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.
 
When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another objectWhen creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object.[[#References|[1]]]  The object also contains its own definition of functionality and storage.  This fact allows the functionality of any object to be changed after creation.  This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage.  An example is below:
 
=Example of prototype based programming in ruby=
The following example of Prototype based programming shows how objects can be reopened and have their methods redefined in ruby
 
<pre>
def x.hello(arg)
    puts "Hello, #{arg}!"
end
 
x.hello("world") # => "Hello, world!"
 
#Now we just need to copy existing objects:


A prototype may be created either ''[[ex nihilo]]'' or by cloning another class.
y = x.clone()
y.hello("world") # => "Hello, world!"


=Inheritance in each method=
#The objects are independent, so each of them can redefine methods without worrying about everyone #else:
A class based design requires that all relationships are created explicitly in the source.  This means that for a class to be a child of another, that relationship must be explicitly stated in the source at compile time.


An object may have its functionality extended during execution by inclusion of a prototype. This means that a object can be given any aspect while the code is executing. See [[Unbounded Polymorphism]]
z = x.clone()


=Negatives of Prototype based programming=
def x.hello(arg)
    puts "Guten Tag, #{arg}!"
end


def z.hello(arg)
    puts "Goodbye, #{arg}!"
end
x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>
[[#References|[3]]]
=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions.  The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects.  It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.
==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]]  This raises concerns over efficiency at run time.


=References=
=References=


[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming
[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming


http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html
http://en.wikipedia.org/wiki/Prototype-based_programming

Latest revision as of 18:40, 30 October 2010

Introduction

One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.[1]

Prototypes vs. Sets

When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:

  • Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
  • Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

Creation using each method

When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either ["ex nihilo"] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object.[1] The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

Example of prototype based programming in ruby

The following example of Prototype based programming shows how objects can be reopened and have their methods redefined in ruby

def x.hello(arg)
    puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
    puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
    puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"

[3]

Criticisms of Prototype based programming

Classes as types

Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[1]

  • Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
  • Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
  • Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

Compiler speed

Compilers written for prototype-based languages are more complex than those written for class based languages.[1] This raises concerns over efficiency at run time.

References

[1] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[2] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[3] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html