Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 2 at

2007-11-14T03:49:13Z

Tmakhij: /* References */

==Programming by contract==

Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The preconditions define the conditions whose truth the caller guarantees to ensure before calling the function, and the postconditions define the conditions whose truth the function guarantees to establish by virtue of its execution. One of the purposes in this is to avoid redundant validity checks at each level in a stack of called functions.

=== Example 1 ===
Consider the following example for counting the number of vowles [1]:

<pre>
int is_vowelpair (const char *p)
{
return is_vowel(*p) && is_vowel (*(p+1));
}

int count_vowelpairs (char *s)
{
int sum = 0;

for (; *s != '\0'; s++)
if (is_vowelpair(s))
sum++;
return sum;
}
</pre>

The functions count_vowelpairs receive as input argument a pointer to a C string. Neither function applies any validity check to the pointer, so there is an implicit precondition that the caller supply a valid pointer. To follow the rules of programming by contract we should make this an explicit precondition, albeit one that is so common and obvious that it hardly seems to need stating.

There are four possibilities for the pointer passed in as argument:

It contains a valid address that is indeed the address of a valid C string (including the null string).
It contains a valid address but the memory at that address does not comprise a valid C string.
It contains a bit pattern that is not a valid address (e.g., it is outside the addressing range, or the memory is not readable).
It contains the null pointer.
Our contract imposes the precondition that the pointer must be valid as specified in the first case above. There is no reasonable way to detect the second case, and for the third case it is usual to delegate detection (and handling) to the exception mechanism of the operating system11.

The fourth case is the interesting one. Null is a valid value for a pointer, but it is (by definition) an invalid address that will generally cause an addressing exception if dereferenced. It is, however, trivial for the function to detect that a null pointer argument has been passed. Therefore, we can propose a general rule that makes life easier for callers of a function: If a pointer to a null object is a valid argument, a null pointer should also be a valid argument with the same meaning. In the specific examples we are studying here, we should change the contract by weakening the precondition to allow the first and fourth cases, and implement the function to immediately return the value 0 if a null pointer is passed as the argument. The purpose of this rule is to relieve callers of the need to make the test for a null pointer; for a language like C the gain is not obvious, but for functional style languages like Lisp the gain is significant.

=== Example 2 ===
Consider the following sort function in python [3]:
<pre>
def sort(a):
"""Sort a list *IN PLACE*.

pre:
# must be a list
isinstance(a, list)

# all elements must be comparable with all other items
forall(range(len(a)),
lambda i: forall(range(len(a)),
lambda j: (a[i] < a[j]) ^ (a[i] >= a[j])))

post[a]:
# length of array is unchanged
len(a) == len(__old__.a)

# all elements given are still in the array
forall(__old__.a, lambda e: __old__.a.count(e) == a.count(e))

# the array is sorted
forall([a[i] >= a[i-1] for i in range(1, len(a))])
</pre>
This tells us everything we need to know about sort. During debugging, these statements are actually executed. If any of the pre-conditions are false, an exception is raised so the caller can be debugged. If any of the post-conditions are false, a similar exception is raised so the sort function can be debugged.

A programming language called Eiffel was created to facilitate Design by Contract. Eiffel provides built-in features to support the implementation of Design by Contract. The example below illustrates those features: [4]

=== Example 3 ===

The following example shows a partial implementation of a bounded queue, with methods put and remove. The pre- and post-conditions for those methods are coded explicitly with the "require" and "ensure" features of Eiffel.

<pre>
class BoundedQueue[G] feature
put(x:G) is
-- add x as newest element
require
not full
do
-- implementation of put
. . .
ensure
not empty
end;
remove is
-- remove oldest element
require
not empty
do
-- implementation of remove
. . .
ensure
not full
end;
empty: BOOLEAN is
-- is the queue empty?
do Result:=. . . end;
full: BOOLEAN is
-- is the queue full?
do Result:=. . . end;
end
</pre>

The assertions are checked at run-time. This checking can be turned on or off as a result of a compilation switch.

Programming by contract places responsibility squarely on the shoulders of the caller for ensuring that specified preconditions for a function are met, and relieves the function of any responsibility for verifying that preconditions are met. As intended, this has the desirable effect of eliminating redundant validity checking. In real life, however, it also has an undesirable side effect: If the caller makes a mistake and does not in fact meet the preconditions, the function is likely to fail, and the cause of the failure may be difficult to track down. A pointer that is null or contains an invalid address is usually easy to diagnose; since an exception will be caused immediately an attempt is made to deference it, but other errors may cause failures far removed from the root cause.

=== Example 4 ===
The following is an example of how Programming by Contract can be implemented in C++:

The first precondition could be called a default precondition. It should be possible to remove such preconditions from object code. However, the second and the third precondition must always be part of the object code.

int not_ok( int& );
int ok( int );
struct Foo { int foo(); int bar() const; };
Foo f;
Foo* f_ptr;
...
void foo( int i )
in
{
not_ok( i ); // error: ’not_ok()’ takes a reference argument
ok( i ); // ok: ’ok()’ takes a value argument
f.foo(); // error: cannot call a non-const member
f_ptr->foo(); // error: not even through a pointer
f_ptr->bar(); // ok: bar is a const member function
f_ptr; // ok: conversion to bool
"a comment"; // ok: conversion to bool
if( ... ); // error: statements not allowed
i = 2; // error: assignment not possible
i > 0; return FAILURE_CODE; // error: ’return’ not allowed
}

Postconditions are much like preconditions: (1) they are optional, (2) can include throw clauses (which are never compiled away), and (3) has the same rules regarding const-correctness. Note that postconditions are only checked when the function exits normally.

int foo( int& i )
out
{
i == in i + 1; // keep track of changes to ’i’
return == 5: terminate(); // call ’terminate()’ on failure
}
do
{
++i;
if( i % 2 == 0 )
return 5;
else
return 4;
}
== See Also ==
http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract<br>
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm<br>
http://www.cs.uno.edu/~c1581/Labs2006/lab7/lab7.htm<br>
http://www.phpunit.de/pocket_guide/3.2/en/test-first-programming.html<br>
http://www.python.org/dev/peps/pep-0316/<br>
http://www.artima.com/cppsource/deepspace2.html<br>
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html<br>
http://www.csc.calpoly.edu/~dstearns/SeniorProjectsWWW/Rideg/dbc.html

== References ==
[1] http://www.ibm.com/developerworks/rational/library/455.html#N10324 <br>
[2] http://archive.eiffel.com/doc/manuals/technology/contract/page.html <br>
[3] http://www.wayforward.net/pycontract/ <br>
[4] http://www.patentstorm.us/patents/6442750-description.html<br>
[5] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1613.pdf

CSC/ECE 517 Fall 2007/wiki3 2 at

2007-11-14T03:48:30Z

Tmakhij:

CSC/ECE 517 Fall 2007/wiki3 2 at

2007-11-14T01:00:47Z

Tmakhij: /* See Also */

==Programming by contract==

Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The preconditions define the conditions whose truth the caller guarantees to ensure before calling the function, and the postconditions define the conditions whose truth the function guarantees to establish by virtue of its execution. One of the purposes in this is to avoid redundant validity checks at each level in a stack of called functions.

=== Example 1 ===
Consider the following example for counting the number of vowles [1]:

<pre>
int is_vowelpair (const char *p)
{
return is_vowel(*p) && is_vowel (*(p+1));
}

int count_vowelpairs (char *s)
{
int sum = 0;

for (; *s != '\0'; s++)
if (is_vowelpair(s))
sum++;
return sum;
}
</pre>

The functions count_vowelpairs receive as input argument a pointer to a C string. Neither function applies any validity check to the pointer, so there is an implicit precondition that the caller supply a valid pointer. To follow the rules of programming by contract we should make this an explicit precondition, albeit one that is so common and obvious that it hardly seems to need stating.

There are four possibilities for the pointer passed in as argument:

It contains a valid address that is indeed the address of a valid C string (including the null string).
It contains a valid address but the memory at that address does not comprise a valid C string.
It contains a bit pattern that is not a valid address (e.g., it is outside the addressing range, or the memory is not readable).
It contains the null pointer.
Our contract imposes the precondition that the pointer must be valid as specified in the first case above. There is no reasonable way to detect the second case, and for the third case it is usual to delegate detection (and handling) to the exception mechanism of the operating system11.

The fourth case is the interesting one. Null is a valid value for a pointer, but it is (by definition) an invalid address that will generally cause an addressing exception if dereferenced. It is, however, trivial for the function to detect that a null pointer argument has been passed. Therefore, we can propose a general rule that makes life easier for callers of a function: If a pointer to a null object is a valid argument, a null pointer should also be a valid argument with the same meaning. In the specific examples we are studying here, we should change the contract by weakening the precondition to allow the first and fourth cases, and implement the function to immediately return the value 0 if a null pointer is passed as the argument. The purpose of this rule is to relieve callers of the need to make the test for a null pointer; for a language like C the gain is not obvious, but for functional style languages like Lisp the gain is significant.

=== Example 2 ===
Consider the following sort function in python [3]:
<pre>
def sort(a):
"""Sort a list *IN PLACE*.

pre:
# must be a list
isinstance(a, list)

# all elements must be comparable with all other items
forall(range(len(a)),
lambda i: forall(range(len(a)),
lambda j: (a[i] < a[j]) ^ (a[i] >= a[j])))

post[a]:
# length of array is unchanged
len(a) == len(__old__.a)

# all elements given are still in the array
forall(__old__.a, lambda e: __old__.a.count(e) == a.count(e))

# the array is sorted
forall([a[i] >= a[i-1] for i in range(1, len(a))])
</pre>
This tells us everything we need to know about sort. During debugging, these statements are actually executed. If any of the pre-conditions are false, an exception is raised so the caller can be debugged. If any of the post-conditions are false, a similar exception is raised so the sort function can be debugged.

A programming language called Eiffel was created to facilitate Design by Contract. Eiffel provides built-in features to support the implementation of Design by Contract. The example below illustrates those features: [4]

=== Example 3 ===

The following example shows a partial implementation of a bounded queue, with methods put and remove. The pre- and post-conditions for those methods are coded explicitly with the "require" and "ensure" features of Eiffel.

<pre>
class BoundedQueue[G] feature
put(x:G) is
-- add x as newest element
require
not full
do
-- implementation of put
. . .
ensure
not empty
end;
remove is
-- remove oldest element
require
not empty
do
-- implementation of remove
. . .
ensure
not full
end;
empty: BOOLEAN is
-- is the queue empty?
do Result:=. . . end;
full: BOOLEAN is
-- is the queue full?
do Result:=. . . end;
end
</pre>

The assertions are checked at run-time. This checking can be turned on or off as a result of a compilation switch.

Programming by contract places responsibility squarely on the shoulders of the caller for ensuring that specified preconditions for a function are met, and relieves the function of any responsibility for verifying that preconditions are met. As intended, this has the desirable effect of eliminating redundant validity checking. In real life, however, it also has an undesirable side effect: If the caller makes a mistake and does not in fact meet the preconditions, the function is likely to fail, and the cause of the failure may be difficult to track down. A pointer that is null or contains an invalid address is usually easy to diagnose; since an exception will be caused immediately an attempt is made to deference it, but other errors may cause failures far removed from the root cause.

== See Also ==
http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract<br>
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm<br>
http://www.cs.uno.edu/~c1581/Labs2006/lab7/lab7.htm<br>
http://www.phpunit.de/pocket_guide/3.2/en/test-first-programming.html<br>
http://www.python.org/dev/peps/pep-0316/<br>
http://www.artima.com/cppsource/deepspace2.html<br>
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html<br>
http://www.csc.calpoly.edu/~dstearns/SeniorProjectsWWW/Rideg/dbc.html

== References ==
[1] http://www.ibm.com/developerworks/rational/library/455.html#N10324 <br>
[2] http://archive.eiffel.com/doc/manuals/technology/contract/page.html <br>
[3] http://www.wayforward.net/pycontract/ <br>
[4] http://www.patentstorm.us/patents/6442750-description.html

CSC/ECE 517 Fall 2007/wiki3 2 at

2007-11-14T00:09:09Z

Tmakhij: /* See Also */

==Programming by contract==

Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The preconditions define the conditions whose truth the caller guarantees to ensure before calling the function, and the postconditions define the conditions whose truth the function guarantees to establish by virtue of its execution. One of the purposes in this is to avoid redundant validity checks at each level in a stack of called functions.

=== Example 1 ===
Consider the following example for counting the number of vowles [1]:

<pre>
int is_vowelpair (const char *p)
{
return is_vowel(*p) && is_vowel (*(p+1));
}

int count_vowelpairs (char *s)
{
int sum = 0;

for (; *s != '\0'; s++)
if (is_vowelpair(s))
sum++;
return sum;
}
</pre>

The functions count_vowelpairs receive as input argument a pointer to a C string. Neither function applies any validity check to the pointer, so there is an implicit precondition that the caller supply a valid pointer. To follow the rules of programming by contract we should make this an explicit precondition, albeit one that is so common and obvious that it hardly seems to need stating.

There are four possibilities for the pointer passed in as argument:

It contains a valid address that is indeed the address of a valid C string (including the null string).
It contains a valid address but the memory at that address does not comprise a valid C string.
It contains a bit pattern that is not a valid address (e.g., it is outside the addressing range, or the memory is not readable).
It contains the null pointer.
Our contract imposes the precondition that the pointer must be valid as specified in the first case above. There is no reasonable way to detect the second case, and for the third case it is usual to delegate detection (and handling) to the exception mechanism of the operating system11.

The fourth case is the interesting one. Null is a valid value for a pointer, but it is (by definition) an invalid address that will generally cause an addressing exception if dereferenced. It is, however, trivial for the function to detect that a null pointer argument has been passed. Therefore, we can propose a general rule that makes life easier for callers of a function: If a pointer to a null object is a valid argument, a null pointer should also be a valid argument with the same meaning. In the specific examples we are studying here, we should change the contract by weakening the precondition to allow the first and fourth cases, and implement the function to immediately return the value 0 if a null pointer is passed as the argument. The purpose of this rule is to relieve callers of the need to make the test for a null pointer; for a language like C the gain is not obvious, but for functional style languages like Lisp the gain is significant.

=== Example 2 ===
Consider the following sort function in python [3]:
<pre>
def sort(a):
"""Sort a list *IN PLACE*.

pre:
# must be a list
isinstance(a, list)

# all elements must be comparable with all other items
forall(range(len(a)),
lambda i: forall(range(len(a)),
lambda j: (a[i] < a[j]) ^ (a[i] >= a[j])))

post[a]:
# length of array is unchanged
len(a) == len(__old__.a)

# all elements given are still in the array
forall(__old__.a, lambda e: __old__.a.count(e) == a.count(e))

# the array is sorted
forall([a[i] >= a[i-1] for i in range(1, len(a))])
</pre>
This tells us everything we need to know about sort. During debugging, these statements are actually executed. If any of the pre-conditions are false, an exception is raised so the caller can be debugged. If any of the post-conditions are false, a similar exception is raised so the sort function can be debugged.

A programming language called Eiffel was created to facilitate Design by Contract. Eiffel provides built-in features to support the implementation of Design by Contract. The example below illustrates those features: [4]

=== Example 3 ===

The following example shows a partial implementation of a bounded queue, with methods put and remove. The pre- and post-conditions for those methods are coded explicitly with the "require" and "ensure" features of Eiffel.

<pre>
class BoundedQueue[G] feature
put(x:G) is
-- add x as newest element
require
not full
do
-- implementation of put
. . .
ensure
not empty
end;
remove is
-- remove oldest element
require
not empty
do
-- implementation of remove
. . .
ensure
not full
end;
empty: BOOLEAN is
-- is the queue empty?
do Result:=. . . end;
full: BOOLEAN is
-- is the queue full?
do Result:=. . . end;
end
</pre>

The assertions are checked at run-time. This checking can be turned on or off as a result of a compilation switch.

Programming by contract places responsibility squarely on the shoulders of the caller for ensuring that specified preconditions for a function are met, and relieves the function of any responsibility for verifying that preconditions are met. As intended, this has the desirable effect of eliminating redundant validity checking. In real life, however, it also has an undesirable side effect: If the caller makes a mistake and does not in fact meet the preconditions, the function is likely to fail, and the cause of the failure may be difficult to track down. A pointer that is null or contains an invalid address is usually easy to diagnose; since an exception will be caused immediately an attempt is made to deference it, but other errors may cause failures far removed from the root cause.

== See Also ==
http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract<br>
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm<br>
http://www.cs.uno.edu/~c1581/Labs2006/lab7/lab7.htm<br>
http://www.phpunit.de/pocket_guide/3.2/en/test-first-programming.html<br>
http://www.python.org/dev/peps/pep-0316/<br>
http://www.artima.com/cppsource/deepspace2.html<br>
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html<br>

== References ==
[1] http://www.ibm.com/developerworks/rational/library/455.html#N10324 <br>
[2] http://archive.eiffel.com/doc/manuals/technology/contract/page.html <br>
[3] http://www.wayforward.net/pycontract/ <br>
[4] http://www.patentstorm.us/patents/6442750-description.html

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-21T18:00:07Z

Tmakhij: /* Example */

== The Question ==

A callback is code that one wants to be called from within a method after that method has been called. That is, it is a method of the caller that is invoked by the callee. Give an example using a closure in Ruby, and show how this is more elegant than similar code in Smalltalk.

== Understanding of the question ==

The question requires us to compare callback using a closure code constructed in RUBY with a similar code constructed in Smalltalk and then show how the RUBY code is more elegant.

== What is Callback? ==

A function passed as an argument is called a callback, since it is "called back" by the other function.[2] In general a callback is a piece of "your" code you ask "some other piece" of code to invoke in certain events, e.g. some code to be executed if a button is clicked on the screen.

In most languages you specify a call back by passing the address of your subroutine to the system you're requesting the callback from.

In RUBY callback is implemented using blocks. A nameless block of code may be passed as an argument to a method for implementation of callback.

=== Blocks and Closures ===

Blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function. For example, a function could perform iteration by passing one item at a time to the nameless function. In Ruby, any method can be called with a block as an implicit argument. Inside the method, you can call the block using the yield keyword with a value. We can create a closure out of a block. A closure is a nameless function. You can pass around a nameless function object, the closure, to another method to customize the behavior of the method. As another example, if you have a sort method to sort an array or list, you can pass a block to define how to compare the elements. This is not iteration. This is not a loop. But it is using blocks. A closure object has code to run, the executable, and state around the code, the scope. So you capture the environment, namely the local variables, in the closure. As a result, you can refer to the local variables inside a closure. Even after the function has returned, and its local scope has been destroyed, the local variables remain in existence as part of the closure object. When no one refers to the closure anymore, it's garbage collected, and the local variables go away.[3]

===Example===

In RUBY any chunk of code between braces {} or between do ... end is a block. This can be associated with a function call also.

Eg.{ puts "Hello" } <- block

def about_block
puts "In the function"
yield
end

about_block {puts "This is the block"} <- Associated with a function call

Output:

In the function<br>
This is the block

''"yield"'' is the keyword which invokes the block of code associated with the function call.

Detailed Explanation of the program : The function about_blocks is defined and called at the end. When it is called the control passes to the first ''"puts"'' in the function. When the next line is executed (''yield'') it refers to the block associated with the function call. So, it prints "This is the block"

== Functor ==

A functor is nothing more than an object that behaves like a function (which is the case in RUBY - everything is an object).[2]

== Approach to the Question ==

Suppose we need to associate actions to a particular button so that it does a required function.
Eg. In a form if we press CLEAR, it should clear the form and SUBMIT should submit the form. Ruby’s blocks are a convenient way to do this.
We assume that on pressing the button a callback method, button_pressed, will be invoked. The obvious way of adding functionality to these buttons is to create subclasses of Button(which is the class) and have each subclass implement its own button_pressed method.
Eg.
class FormButton < Button
def initialize
super("Submit") # invoke Button's initialize
end
def button_pressed
# do submit actions...
end
end
submit_button = FormButton.new
This will lead to a large number of subclasses. We can fix this problem using blocks in RUBY.
pressbutton = PressButton.new
class FormButton < Button
def initialize(label, &action)
super(label)
@action = action
end
def button_pressed
@action.call(self)
end
end
submit_button = FormButton.new("Submit") { pressbutton.submit }
reset_button = FormButton.new("Clear") { pressbutton.reset }

The key to all this is the second parameter to FormButton#initialize. If the last parameter in a method definition is prefixed with an ampersand (such as &action), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. When the callback method button_pressed is invoked, we use the Proc#call method on that object to invoke the block.

== Comparisons of Smalltalk and Ruby code ==

Smalltalk

foo
| xs |
xs := #(1 2 3 4).
xs do: [:x | ^x].
^0
bar
Transcript show: (self foo) "prints 1"

In Smalltalk, ^ will return from method foo, and not just from the closure. do: is defined as a plain method, and there is nothing special about it.

foo
^[ x: | ^x ]
bar
| f |
f := self foo.
f value: 123 "error!"

When block returned by method foo is invoked, it attempts to return a value from foo. Since the call to foo has already completed, this operation results in an error.

Ruby

def foo
f = Proc.new { return "return from foo from inside proc" }
f.call # control leaves foo here
return "return from foo"
end

def bar
f = lambda { return "return from lambda" }
f.call # control does not leave bar here
return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

It allows the programmer to choose the way he wants "return" to be captured.Both Proc.new and lambda in this example are ways to create a closure.[4]

== References ==

1. http://mccammon.ucsd.edu/~oompaa/Oompaa/oompaa/global/doc/callback.html<br>
2. http://forum.java.sun.com/thread.jspa?threadID=485166&messageID=2269118<br>
3. http://www.artima.com/intv/closures.html<br>
4. http://en.wikipedia.org/wiki/Closure_(computer_science)<br>
5. The Pragmatic Programmers - Programming Ruby

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-20T02:58:26Z

Tmakhij: /* References */

== The Question ==

A callback is code that one wants to be called from within a method after that method has been called. That is, it is a method of the caller that is invoked by the callee. Give an example using a closure in Ruby, and show how this is more elegant than similar code in Smalltalk.

== Understanding of the question ==

The question requires us to compare callback using a closure code constructed in RUBY with a similar code constructed in Smalltalk and then show how the RUBY code is more elegant.

== What is Callback? ==

A function passed as an argument is called a callback, since it is "called back" by the other function.[2] In general a callback is a piece of "your" code you ask "some other piece" of code to invoke in certain events, e.g. some code to be executed if a button is clicked on the screen.

In most languages you specify a call back by passing the address of your subroutine to the system you're requesting the callback from.

In RUBY callback is implemented using blocks. A nameless block of code may be passed as an argument to a method for implementation of callback.

=== Blocks and Closures ===

Blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function. For example, a function could perform iteration by passing one item at a time to the nameless function. In Ruby, any method can be called with a block as an implicit argument. Inside the method, you can call the block using the yield keyword with a value. We can create a closure out of a block. A closure is a nameless function. You can pass around a nameless function object, the closure, to another method to customize the behavior of the method. As another example, if you have a sort method to sort an array or list, you can pass a block to define how to compare the elements. This is not iteration. This is not a loop. But it is using blocks. A closure object has code to run, the executable, and state around the code, the scope. So you capture the environment, namely the local variables, in the closure. As a result, you can refer to the local variables inside a closure. Even after the function has returned, and its local scope has been destroyed, the local variables remain in existence as part of the closure object. When no one refers to the closure anymore, it's garbage collected, and the local variables go away.[3]

===Example===

def count(x)
a1, a2 = 1, 1
while a1 <= x
yield a1
a1, a2 = a2, a1+a2
end
end
count(1000) {|f| print f, " " }

== Functor ==

A functor is nothing more than an object that behaves like a function (which is the case in RUBY - everything is an object).[2]

== Approach to the Question ==

Suppose we need to associate actions to a particular button so that it does a required function.
Eg. In a form if we press CLEAR, it should clear the form and SUBMIT should submit the form. Ruby’s blocks are a convenient way to do this.
We assume that on pressing the button a callback method, button_pressed, will be invoked. The obvious way of adding functionality to these buttons is to create subclasses of Button(which is the class) and have each subclass implement its own button_pressed method.
Eg.
class FormButton < Button
def initialize
super("Submit") # invoke Button's initialize
end
def button_pressed
# do submit actions...
end
end
submit_button = FormButton.new
This will lead to a large number of subclasses. We can fix this problem using blocks in RUBY.
pressbutton = PressButton.new
class FormButton < Button
def initialize(label, &action)
super(label)
@action = action
end
def button_pressed
@action.call(self)
end
end
submit_button = FormButton.new("Submit") { pressbutton.submit }
reset_button = FormButton.new("Clear") { pressbutton.reset }

The key to all this is the second parameter to FormButton#initialize. If the last parameter in a method definition is prefixed with an ampersand (such as &action), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. When the callback method button_pressed is invoked, we use the Proc#call method on that object to invoke the block.

== Comparisons of Smalltalk and Ruby code ==

Smalltalk

foo
| xs |
xs := #(1 2 3 4).
xs do: [:x | ^x].
^0
bar
Transcript show: (self foo) "prints 1"

In Smalltalk, ^ will return from method foo, and not just from the closure. do: is defined as a plain method, and there is nothing special about it.

foo
^[ x: | ^x ]
bar
| f |
f := self foo.
f value: 123 "error!"

When block returned by method foo is invoked, it attempts to return a value from foo. Since the call to foo has already completed, this operation results in an error.

Ruby

def foo
f = Proc.new { return "return from foo from inside proc" }
f.call # control leaves foo here
return "return from foo"
end

def bar
f = lambda { return "return from lambda" }
f.call # control does not leave bar here
return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

It allows the programmer to choose the way he wants "return" to be captured.Both Proc.new and lambda in this example are ways to create a closure.[4]

== References ==

1. http://mccammon.ucsd.edu/~oompaa/Oompaa/oompaa/global/doc/callback.html<br>
2. http://forum.java.sun.com/thread.jspa?threadID=485166&messageID=2269118<br>
3. http://www.artima.com/intv/closures.html<br>
4. http://en.wikipedia.org/wiki/Closure_(computer_science)<br>
5. The Pragmatic Programmers - Programming Ruby

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-20T02:55:42Z

Tmakhij: /* Example */

== The Question ==

A callback is code that one wants to be called from within a method after that method has been called. That is, it is a method of the caller that is invoked by the callee. Give an example using a closure in Ruby, and show how this is more elegant than similar code in Smalltalk.

== Understanding of the question ==

The question requires us to compare callback using a closure code constructed in RUBY with a similar code constructed in Smalltalk and then show how the RUBY code is more elegant.

== What is Callback? ==

A function passed as an argument is called a callback, since it is "called back" by the other function.[2] In general a callback is a piece of "your" code you ask "some other piece" of code to invoke in certain events, e.g. some code to be executed if a button is clicked on the screen.

In most languages you specify a call back by passing the address of your subroutine to the system you're requesting the callback from.

In RUBY callback is implemented using blocks. A nameless block of code may be passed as an argument to a method for implementation of callback.

=== Blocks and Closures ===

Blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function. For example, a function could perform iteration by passing one item at a time to the nameless function. In Ruby, any method can be called with a block as an implicit argument. Inside the method, you can call the block using the yield keyword with a value. We can create a closure out of a block. A closure is a nameless function. You can pass around a nameless function object, the closure, to another method to customize the behavior of the method. As another example, if you have a sort method to sort an array or list, you can pass a block to define how to compare the elements. This is not iteration. This is not a loop. But it is using blocks. A closure object has code to run, the executable, and state around the code, the scope. So you capture the environment, namely the local variables, in the closure. As a result, you can refer to the local variables inside a closure. Even after the function has returned, and its local scope has been destroyed, the local variables remain in existence as part of the closure object. When no one refers to the closure anymore, it's garbage collected, and the local variables go away.[3]

===Example===

def count(x)
a1, a2 = 1, 1
while a1 <= x
yield a1
a1, a2 = a2, a1+a2
end
end
count(1000) {|f| print f, " " }

== Functor ==

A functor is nothing more than an object that behaves like a function (which is the case in RUBY - everything is an object).[2]

== Approach to the Question ==

Suppose we need to associate actions to a particular button so that it does a required function.
Eg. In a form if we press CLEAR, it should clear the form and SUBMIT should submit the form. Ruby’s blocks are a convenient way to do this.
We assume that on pressing the button a callback method, button_pressed, will be invoked. The obvious way of adding functionality to these buttons is to create subclasses of Button(which is the class) and have each subclass implement its own button_pressed method.
Eg.
class FormButton < Button
def initialize
super("Submit") # invoke Button's initialize
end
def button_pressed
# do submit actions...
end
end
submit_button = FormButton.new
This will lead to a large number of subclasses. We can fix this problem using blocks in RUBY.
pressbutton = PressButton.new
class FormButton < Button
def initialize(label, &action)
super(label)
@action = action
end
def button_pressed
@action.call(self)
end
end
submit_button = FormButton.new("Submit") { pressbutton.submit }
reset_button = FormButton.new("Clear") { pressbutton.reset }

The key to all this is the second parameter to FormButton#initialize. If the last parameter in a method definition is prefixed with an ampersand (such as &action), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. When the callback method button_pressed is invoked, we use the Proc#call method on that object to invoke the block.

== Comparisons of Smalltalk and Ruby code ==

Smalltalk

foo
| xs |
xs := #(1 2 3 4).
xs do: [:x | ^x].
^0
bar
Transcript show: (self foo) "prints 1"

In Smalltalk, ^ will return from method foo, and not just from the closure. do: is defined as a plain method, and there is nothing special about it.

foo
^[ x: | ^x ]
bar
| f |
f := self foo.
f value: 123 "error!"

When block returned by method foo is invoked, it attempts to return a value from foo. Since the call to foo has already completed, this operation results in an error.

Ruby

def foo
f = Proc.new { return "return from foo from inside proc" }
f.call # control leaves foo here
return "return from foo"
end

def bar
f = lambda { return "return from lambda" }
f.call # control does not leave bar here
return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

It allows the programmer to choose the way he wants "return" to be captured.Both Proc.new and lambda in this example are ways to create a closure.[4]

== References ==

1. http://mccammon.ucsd.edu/~oompaa/Oompaa/oompaa/global/doc/callback.html<br>
2. http://forum.java.sun.com/thread.jspa?threadID=485166&messageID=2269118<br>
3. http://www.artima.com/intv/closures.html<br>
4. http://en.wikipedia.org/wiki/Closure_(computer_science)

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-20T02:54:54Z

Tmakhij: /* Blocks and Closures */

== The Question ==

A callback is code that one wants to be called from within a method after that method has been called. That is, it is a method of the caller that is invoked by the callee. Give an example using a closure in Ruby, and show how this is more elegant than similar code in Smalltalk.

== Understanding of the question ==

The question requires us to compare callback using a closure code constructed in RUBY with a similar code constructed in Smalltalk and then show how the RUBY code is more elegant.

== What is Callback? ==

A function passed as an argument is called a callback, since it is "called back" by the other function.[2] In general a callback is a piece of "your" code you ask "some other piece" of code to invoke in certain events, e.g. some code to be executed if a button is clicked on the screen.

In most languages you specify a call back by passing the address of your subroutine to the system you're requesting the callback from.

In RUBY callback is implemented using blocks. A nameless block of code may be passed as an argument to a method for implementation of callback.

=== Blocks and Closures ===

Blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function. For example, a function could perform iteration by passing one item at a time to the nameless function. In Ruby, any method can be called with a block as an implicit argument. Inside the method, you can call the block using the yield keyword with a value. We can create a closure out of a block. A closure is a nameless function. You can pass around a nameless function object, the closure, to another method to customize the behavior of the method. As another example, if you have a sort method to sort an array or list, you can pass a block to define how to compare the elements. This is not iteration. This is not a loop. But it is using blocks. A closure object has code to run, the executable, and state around the code, the scope. So you capture the environment, namely the local variables, in the closure. As a result, you can refer to the local variables inside a closure. Even after the function has returned, and its local scope has been destroyed, the local variables remain in existence as part of the closure object. When no one refers to the closure anymore, it's garbage collected, and the local variables go away.[3]

===Example===

def count(x)
a1, a2 = 1, 1
while a1 <= x
yield a1
a1, a2 = a2, a1+a2
end
end

count(1000) {|f| print f, " " }

== Functor ==

A functor is nothing more than an object that behaves like a function (which is the case in RUBY - everything is an object).[2]

== Approach to the Question ==

Suppose we need to associate actions to a particular button so that it does a required function.
Eg. In a form if we press CLEAR, it should clear the form and SUBMIT should submit the form. Ruby’s blocks are a convenient way to do this.
We assume that on pressing the button a callback method, button_pressed, will be invoked. The obvious way of adding functionality to these buttons is to create subclasses of Button(which is the class) and have each subclass implement its own button_pressed method.
Eg.
class FormButton < Button
def initialize
super("Submit") # invoke Button's initialize
end
def button_pressed
# do submit actions...
end
end
submit_button = FormButton.new
This will lead to a large number of subclasses. We can fix this problem using blocks in RUBY.
pressbutton = PressButton.new
class FormButton < Button
def initialize(label, &action)
super(label)
@action = action
end
def button_pressed
@action.call(self)
end
end
submit_button = FormButton.new("Submit") { pressbutton.submit }
reset_button = FormButton.new("Clear") { pressbutton.reset }

The key to all this is the second parameter to FormButton#initialize. If the last parameter in a method definition is prefixed with an ampersand (such as &action), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. When the callback method button_pressed is invoked, we use the Proc#call method on that object to invoke the block.

== Comparisons of Smalltalk and Ruby code ==

Smalltalk

foo
| xs |
xs := #(1 2 3 4).
xs do: [:x | ^x].
^0
bar
Transcript show: (self foo) "prints 1"

In Smalltalk, ^ will return from method foo, and not just from the closure. do: is defined as a plain method, and there is nothing special about it.

foo
^[ x: | ^x ]
bar
| f |
f := self foo.
f value: 123 "error!"

When block returned by method foo is invoked, it attempts to return a value from foo. Since the call to foo has already completed, this operation results in an error.

Ruby

def foo
f = Proc.new { return "return from foo from inside proc" }
f.call # control leaves foo here
return "return from foo"
end

def bar
f = lambda { return "return from lambda" }
f.call # control does not leave bar here
return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

It allows the programmer to choose the way he wants "return" to be captured.Both Proc.new and lambda in this example are ways to create a closure.[4]

== References ==

1. http://mccammon.ucsd.edu/~oompaa/Oompaa/oompaa/global/doc/callback.html<br>
2. http://forum.java.sun.com/thread.jspa?threadID=485166&messageID=2269118<br>
3. http://www.artima.com/intv/closures.html<br>
4. http://en.wikipedia.org/wiki/Closure_(computer_science)

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-15T02:10:25Z

Tmakhij:

== The Question ==

A callback is code that one wants to be called from within a method after that method has been called. That is, it is a method of the caller that is invoked by the callee. Give an example using a closure in Ruby, and show how this is more elegant than similar code in Smalltalk.

== Understanding of the question ==

The question requires us to compare callback using a closure code constructed in RUBY with a similar code constructed in Smalltalk and then show how the RUBY code is more elegant.

== What is Callback? ==

A function passed as an argument is called a callback, since it is "called back" by the other function.[2] In general a callback is a piece of "your" code you ask "some other piece" of code to invoke in certain events, e.g. some code to be executed if a button is clicked on the screen.

In most languages you specify a call back by passing the address of your subroutine to the system you're requesting the callback from.

In RUBY callback is implemented using blocks. A nameless block of code may be passed as an argument to a method for implementation of callback.

=== Blocks and Closures ===

Blocks are basically nameless functions. You can pass a nameless function to another function, and then that function can invoke the passed-in nameless function. For example, a function could perform iteration by passing one item at a time to the nameless function. In Ruby, any method can be called with a block as an implicit argument. Inside the method, you can call the block using the yield keyword with a value. We can create a closure out of a block. A closure is a nameless function. You can pass around a nameless function object, the closure, to another method to customize the behavior of the method. As another example, if you have a sort method to sort an array or list, you can pass a block to define how to compare the elements. This is not iteration. This is not a loop. But it is using blocks. A closure object has code to run, the executable, and state around the code, the scope. So you capture the environment, namely the local variables, in the closure. As a result, you can refer to the local variables inside a closure. Even after the function has returned, and its local scope has been destroyed, the local variables remain in existence as part of the closure object. When no one refers to the closure anymore, it's garbage collected, and the local variables go away.[3]

== Functor ==

A functor is nothing more than an object that behaves like a function (which is the case in RUBY - everything is an object).[2]

== Approach to the Question ==

Suppose we need to associate actions to a particular button so that it does a required function.
Eg. In a form if we press CLEAR, it should clear the form and SUBMIT should submit the form. Ruby’s blocks are a convenient way to do this.
We assume that on pressing the button a callback method, button_pressed, will be invoked. The obvious way of adding functionality to these buttons is to create subclasses of Button(which is the class) and have each subclass implement its own button_pressed method.
Eg.
class FormButton < Button
def initialize
super("Submit") # invoke Button's initialize
end
def button_pressed
# do submit actions...
end
end
submit_button = FormButton.new
This will lead to a large number of subclasses. We can fix this problem using blocks in RUBY.
pressbutton = PressButton.new
class FormButton < Button
def initialize(label, &action)
super(label)
@action = action
end
def button_pressed
@action.call(self)
end
end
submit_button = FormButton.new("Submit") { pressbutton.submit }
reset_button = FormButton.new("Clear") { pressbutton.reset }

The key to all this is the second parameter to FormButton#initialize. If the last parameter in a method definition is prefixed with an ampersand (such as &action), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. When the callback method button_pressed is invoked, we use the Proc#call method on that object to invoke the block.

== Comparisons of Smalltalk and Ruby code ==

Smalltalk

foo
| xs |
xs := #(1 2 3 4).
xs do: [:x | ^x].
^0
bar
Transcript show: (self foo) "prints 1"

In Smalltalk, ^ will return from method foo, and not just from the closure. do: is defined as a plain method, and there is nothing special about it.

foo
^[ x: | ^x ]
bar
| f |
f := self foo.
f value: 123 "error!"

When block returned by method foo is invoked, it attempts to return a value from foo. Since the call to foo has already completed, this operation results in an error.

Ruby

def foo
f = Proc.new { return "return from foo from inside proc" }
f.call # control leaves foo here
return "return from foo"
end

def bar
f = lambda { return "return from lambda" }
f.call # control does not leave bar here
return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

It allows the programmer to choose the way he wants "return" to be captured.Both Proc.new and lambda in this example are ways to create a closure.[4]

== References ==

1. http://mccammon.ucsd.edu/~oompaa/Oompaa/oompaa/global/doc/callback.html<br>
2. http://forum.java.sun.com/thread.jspa?threadID=485166&messageID=2269118<br>
3. http://www.artima.com/intv/closures.html<br>
4. http://en.wikipedia.org/wiki/Closure_(computer_science)

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-15T00:26:21Z

Tmakhij:

CSC/ECE 517 Fall 2007/wiki1 2 316

2007-09-15T00:16:56Z

Tmakhij: