referencing, closures, classes

[David McDivitt]

I am new to Perl going through the book by Deitel, "Perl How to Program". I
went through the first half the book pretty fast and only did a few of the
programming examples to understand. I even made a good application with what
I read this far having four web pages, CGI functionality, functions, hashes,
Perl default variables, and code optimizations.

I seem to be stuck on the conceptual matter of referencing, closures, and
classes. The book is good to the extent it covers the whole language and
represents a good plan for learning the language. Unfortunately, I have
found the book lacking in description of a few key points. They are glossed
over with sentences lacking sufficient detail or are ambiguous. It is as if
the author is impatient to move on. Not only am I learning the language
myself to write production applications, but I am also leaving behind a
methodology for others here to follow. When parts of the book need
clarification I find it for my own benefit, then create a text document
having the problem chapter and section. It is my hope others can go through
the book and read these little text files for clarification when necessary.

I don't like to assume things, and I don't like to do things just because
the book or so-and-so says so. I have read several articles on referencing,
closures, and classes, but am unable to understand exactly why it works and
what Perl is doing with these. I could move on in the book then get what I
want through osmosis later on, but prefer to understand these points right
now. Sometimes I make things too complicated, too.

The key seems to be basic referencing, which is easy to understand, coupled
with anonymous referencing, which is also easy to understand. With closures
and classes, the problem is understanding what is being left behind and why.
What exactly is the syntax doing? It seems the way closures are created is
the manner in which a routine exits. The author left a good trail, with all
the preliminaries in place, but failed to put everything together at the end
to enable whatever visualization. I read
[url]http://www.perldoc.com/perl5.6/pod/perltoot.html[/url]. Though quite good, it
still did not complete the picture for me. Any comments would be
appreciated. Thanks

[Matija Papec]

X-Ftn-To: David McDivitt

David McDivitt <x12code-del@del-yahoo.com> wrote:

>The key seems to be basic referencing, which is easy to understand, coupled
>with anonymous referencing, which is also easy to understand. With closures
>and classes, the problem is understanding what is being left behind and why.
>What exactly is the syntax doing? It seems the way closures are created is
>the manner in which a routine exits. The author left a good trail, with all
>the preliminaries in place, but failed to put everything together at the end
>to enable whatever visualization. I read
>[url]http://www.perldoc.com/perl5.6/pod/perltoot.html[/url]. Though quite good, it
>still did not complete the picture for me. Any comments would be
>appreciated. Thanks

Closure is a /subroutine/ which refers to lexical variables declared outside
the subroutine itself.. so Damian defines closures in OO Perl.

What you're missing in your picture?



--
Matija

[Uri Guttman]

>>>>> "DM" == David McDivitt <x12code-del@del-yahoo.com> writes:

DM> I am new to Perl going through the book by Deitel, "Perl How to
DM> Program". I went through the first half the book pretty fast and
DM> only did a few of the programming examples to understand. I even
DM> made a good application with what I read this far having four web
DM> pages, CGI functionality, functions, hashes, Perl default
DM> variables, and code optimizations.

get a better book. there is no need for most newbies to use closures.

DM> I seem to be stuck on the conceptual matter of referencing,
DM> closures, and classes. The book is good to the extent it covers
DM> the whole language and represents a good plan for learning the
DM> language. Unfortunately, I have found the book lacking in
DM> description of a few key points. They are glossed over with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

see, it is a bad book if it does that. go to learn.perl.org for more on
better books (including a good one that is free online).


DM> sentences lacking sufficient detail or are ambiguous. It is as if
DM> the author is impatient to move on. Not only am I learning the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

another sign of a bad book.

DM> language myself to write production applications, but I am also
DM> leaving behind a methodology for others here to follow. When parts
DM> of the book need clarification I find it for my own benefit, then
DM> create a text document having the problem chapter and section. It
DM> is my hope others can go through the book and read these little
DM> text files for clarification when necessary.

DM> I don't like to assume things, and I don't like to do things just
DM> because the book or so-and-so says so. I have read several
DM> articles on referencing, closures, and classes, but am unable to
DM> understand exactly why it works and what Perl is doing with
DM> these. I could move on in the book then get what I want through
DM> osmosis later on, but prefer to understand these points right
DM> now. Sometimes I make things too complicated, too.

why do you think you need closures? closures are not really related to
references (even though closures are made with anon code refs) in general.


DM> The key seems to be basic referencing, which is easy to
DM> understand, coupled with anonymous referencing, which is also easy
DM> to understand. With closures and classes, the problem is

references don't know if they are 'regular' or 'anonymous', they are
just references. if your book separates them like that, then get a
better book.

DM> understanding what is being left behind and why. What exactly is
DM> the syntax doing? It seems the way closures are created is the
DM> manner in which a routine exits. The author left a good trail,
DM> with all the preliminaries in place, but failed to put everything
DM> together at the end to enable whatever visualization. I read
DM> [url]http://www.perldoc.com/perl5.6/pod/perltoot.html[/url]. Though quite
DM> good, it still did not complete the picture for me. Any comments
DM> would be appreciated. Thanks

get a better book. this one sounds awful from only your description.

here are a few to start with. search google in this group for more
recommendations.

learning perl
elements of programming with perl
programming perl


uri

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]
Damian Conway Class in Boston - Sept 2003 -- [url]http://www.stemsystems.com/class[/url]

[Charlton Wilbur]

>>>>> "UG" == Uri Guttman <uri@stemsystems.com> writes:

UG> get a better book. this one sounds awful from only your
UG> description.

The Deitel & Deitel _C: How to Program_ was a very good book; it's the
one I was taught C from. I've since replaced it with K&R2 (which got
stolen) and with Harbison & Steele, but it was a very good book all
the same.

Their _C++: How to Program_ was disappointing, as was their _Java: How
to Program_. I'm not surprised that the Perl one is horrible, alas.

Charlton

--
cwilbur at chromatico dot net
cwilbur at mac dot com

[David McDivitt]

Here is what the book says:

*********

Anonymous functions come into existence at runtime. The part of the code in
which an anonymous function is created has it's own lexical context <ok>.
The values of variables created in the same lexical context as an anonymous
function can be used by the anonymous function when it is called later in
the program <ok>. Anonymous functions save the information about the context
in which they were created and execute as if they were still in that
context. The anonymous functions act as "closures" with respect to lexical
variables <taken for granted but OK>.

5 use warnings;
6 use strict;
7
8 print( "The number is square( 5 ).\n" );
9 print( "The number is ${ \square( 5 ) }.\n" );
10
11 sub square
12 {
13 my $x = shift();
14 return $x * $x;
15 }

The number is square( 5 ).
The number is 25.
fig 13.7

An example where this can be useful is when a function returns an anonymous
function reference. The function reference will contain the state
information pertaining for the lexical context in which it was created.
Figure 13.8 demonstrates this concept.

Function "animalInFood"(lines 8-16) returns a reference to an anonymous
function (defined at lines 11 thru 15). Line 10 creates a lexical variable
"$x", which stores the value passed to function "animalInFood" as an
argument. Note that the anonymous function uses the lexical variable "$x" in
line 14. Each time the "animalInFood" function is called, a new "$x" is
created because it is declared with the "my" keyword. When the anonymous
function is created on line 11, the "$x" it refers to is the specific "$x"
that exists at the time the function is created, not the value that "$x"
holds when the anonymous function is called. This association of the
variable "$x" in the closure with the specific instance of "$x", rather than
the name "$x", is known as "deep binding". Only lexical variables provide
deep binding. If we used the "local" keyword on line 10 instead of "my", we
would not have deep binding and the anonymous function returned would not be
a closure.

5 use warnings;
6 use strict;
7
8 sub animalInFood
9 {
10 my $x = shift();
11 return sub #what the hell does return sub mean?
12 { #no description given anywhere
13 my $y = shift();
14 print( "There is a $x in my $y!\n" );
15 };
16 }
17
18 my &$flyInFood = animalInFood( "fly" );
19 my &$frogInFood = animalInFood( "frog" );
20
21 &$flyInFood( "soup" );
22 &$frogInFood( "coffee" );

There is a fly in my soup!
There is a frog in my coffee!
fig 13.8

You can see that "animalInFood returns closures because when we assign
variable "$flyInFood" the closure returned by passing "animalInFood" the
word "fly", then call "animalInFood" again with the value "frog". Each
closure is stored in a reference. These references are used at lines 21 and
22 to invoke each closure. Note that the closure invoked at line 21 prints a
string containing the word "fly", which was passed to the first call to
"animalInFood". Similarly, the closure invoked at line 22 prints a string
containing the word "frog", which was passed to the second call to
"animalInFood".

********************************

I don't know what I'm supposed to get from this. It is not well written in
my opinion and I fail to get the point of even reading it. Closures seem to
be very important however, and understanding closures would seem to help one
understand classes, too. Thanks

>Subject: Re: referencing, closures, classes
>Date: Thu, 18 Sep 2003 21:41:40 +0200
>
>X-Ftn-To: David McDivitt
>
>David McDivitt <x12code-del@del-yahoo.com> wrote:

>>The key seems to be basic referencing, which is easy to understand, coupled
>>with anonymous referencing, which is also easy to understand. With closures
>>and classes, the problem is understanding what is being left behind and why.
>>What exactly is the syntax doing? It seems the way closures are created is
>>the manner in which a routine exits. The author left a good trail, with all
>>the preliminaries in place, but failed to put everything together at the end
>>to enable whatever visualization. I read
>>[url]http://www.perldoc.com/perl5.6/pod/perltoot.html[/url]. Though quite good, it
>>still did not complete the picture for me. Any comments would be
>>appreciated. Thanks

>
>Closure is a /subroutine/ which refers to lexical variables declared outside
>the subroutine itself.. so Damian defines closures in OO Perl.
>
>What you're missing in your picture?

[David McDivitt]

The book has been OK to present. When things get too complex it breaks down,
and the book seems a recital to someone already knowledgeable. It does give
a good plan. One thing I don't like is the way it talks in ridiculously
simple terms sometimes, as if to an infant, then glosses over crucial stuff
with no descriptive effort at all. Each little thing has one time slice. If
easy, the one thing is spread monotonously across the entire timeslice. If
difficult, the one thing is crammed into the same size timeslice.

I took two Java classes and in the second Deitel, "Java How to Program" was
used. For the most part it was OK. The entire book was also on the
accompanying CD, as well as program and runtime examples I could just click
on.

I was hoping to get the same thing this time; CD version of the book, etc.
Boy am I disappointed.

>From: Charlton Wilbur <cwilbur@mithril.chromatico.net>
>Subject: Re: referencing, closures, classes
>Date: Thu, 18 Sep 2003 21:30:06 GMT
>

>>>>>> "UG" == Uri Guttman <uri@stemsystems.com> writes:

>
> UG> get a better book. this one sounds awful from only your
> UG> description.
>
>The Deitel & Deitel _C: How to Program_ was a very good book; it's the
>one I was taught C from. I've since replaced it with K&R2 (which got
>stolen) and with Harbison & Steele, but it was a very good book all
>the same.
>
>Their _C++: How to Program_ was disappointing, as was their _Java: How
>to Program_. I'm not surprised that the Perl one is horrible, alas.
>
>Charlton
>

[Eric Schwartz]

David McDivitt <x12code-del@del-yahoo.com> writes:

> 5 use warnings;
> 6 use strict;

Yaay for these, anyway! Too many books omit them.

> 8 sub animalInFood
> 9 {
> 10 my $x = shift();

Here, x is a lexical. Don't obsess about the fact that it exists in a sub.

> 11 return sub #what the hell does return sub mean?
> 12 { #no description given anywhere

I assume you know what return does (returns a value or values from a
function) and what sub does (defines a subroutine). This combines the
two-- defines a subroutine, and returns a reference to it.

> 13 my $y = shift();

The subroutine being created has one parameter.

> 14 print( "There is a $x in my $y!\n" );

Here's where "closure" comes into it. Notice that this anonymous
subroutine refers to $x. Since $x is a lexical variable outside the
scope of this subroutine, its value is captured /as of the time the
sub is defined/, and that value will be used whenever the sub is
returned.

> 15 };
> 16 }
> 17
> 18 my &$flyInFood = animalInFood( "fly" );

The & is unnecessary here. animalInFood is returning a reference to
an anonymous sub that takes one argument. In that sub, $x is set to
"fly", since that's the value it had at the time the sub was defined,
and $y will take whatever value you give it when you call the sub.

> 19 my &$frogInFood = animalInFood( "frog" );

Likewise, remove the &. Here, animalInFood returns a reference to a
subroutine in which takes one argument, and where $x is set to "frog".

> 21 &$flyInFood( "soup" );
> 22 &$frogInFood( "coffee" );

Here, you dereference the subroutines you created by calling
animalInFood above, and pass them arguments. They retain the value of
$x from when they were defined, and take $y from the arguments you
pass to them.

You can also call these sub refs as:

$flyInFood->("soup")
$frogInFood->("coffee")

> I don't know what I'm supposed to get from this. It is not well written in
> my opinion and I fail to get the point of even reading it. Closures seem to
> be very important however, and understanding closures would seem to help one
> understand classes, too. Thanks

99% of the Perl programs I write don't need or use closures. I'd say
100%, except that I'll bet I've done it once or twice, and just forgot
about it. I have no idea whether my experience will reflect yours,
however.

It's confusing and hard to follow when things are upside-down.
Why not?
Also, please do not top-post.

If you read the Posting Guidelines, which are posted here regularly,
you'll be more likely to get better responses than mine, I'm sure.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

[Bob Walton]

David McDivitt wrote:

....

>
> 5 use warnings;
> 6 use strict;
> 7
> 8 sub animalInFood
> 9 {
> 10 my $x = shift();
> 11 return sub #what the hell does return sub mean?
> 12 { #no description given anywhere

The "return sub {...}" is returning a code reference to the anonymous
sub consisting of the code between the braces (see perldoc -f sub to see
what the sub function does). Bear in mind that when there is no
semicolon or ending brace, the Perl expression isn't over yet -- it
continues on subsequent lines. In this case, that anonymous sub is a
closure because it uses $x, a lexical variable which was already defined
in the scope of the sub at the time the sub was defined. You will note
that if you call the returned code reference, it remembers the value of
the in-scope lexical at the time the sub was defined. There is no magic
to this, and actually, it barely warrants the special name "closure"
(which name, as far as I can tell, might as well be any made-up name, as
the ordinary concept of "closure" seems to bear no relation to this).
It is simply a matter of the normal behavior of scoped lexical
variables. Each time "animalInFood" is called, another anonymous code
reference consisting of a sub with $x already in its scope with the
value is has at the moment is created. When that code reference is
executed later, it remembers its $x. That's all there is to it. For
fun, try writing closures which modify their already-in-scope variables.

> 13 my $y = shift();
> 14 print( "There is a $x in my $y!\n" );
> 15 };
> 16 }
> 17
> 18 my &$flyInFood = animalInFood( "fly" );
> 19 my &$frogInFood = animalInFood( "frog" );
> 20
> 21 &$flyInFood( "soup" );
> 22 &$frogInFood( "coffee" );
>
> There is a fly in my soup!
> There is a frog in my coffee!
> fig 13.8
>
> You can see that "animalInFood returns closures because when we assign
> variable "$flyInFood" the closure returned by passing "animalInFood" the
> word "fly", then call "animalInFood" again with the value "frog". Each
> closure is stored in a reference. These references are used at lines 21 and
> 22 to invoke each closure. Note that the closure invoked at line 21 prints a
> string containing the word "fly", which was passed to the first call to
> "animalInFood". Similarly, the closure invoked at line 22 prints a string
> containing the word "frog", which was passed to the second call to
> "animalInFood".
>
> ********************************
>
> I don't know what I'm supposed to get from this. It is not well written in
> my opinion and I fail to get the point of even reading it. Closures seem to
> be very important however, and understanding closures would seem to help one
> understand classes, too. Thanks

Well, it seems fairly clear to me, but I do think it would be better to
describe the phenomenon as simply the expected behavior of scoped
lexical variables, just exactly like what happens in any other scope. I
don't know how important they are -- I guess they can be pretty
important for generating obfuscated code, maybe. And they do let you
create truly private variables which absolutely nothing can touch other
than your own methods when you create modules. But that probably isn't
very important either (hey, someone can just modify the code of your
module if they really want to, so what did it really gain? Oh, yeah, it
obfuscated it to the point where they couldn't understand it anyway, so
maybe it did keep your module private :-).).


....


--
Bob Walton

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David,

I would *strongly* recommend Damian Conway's excellent book, _Object
Oriented Perl_. It covers references, closures, objects, and classes in
great detail, and is very readable and clear, imho. Well worth the cover
price.

In a nutshell: A reference is a scalar value that holds information
about a scalar, array, hash, subroutine, filehandle, etc. It is sort of
analogous to a pointer in C or Pascal (if you know C or Pascal), except
that it holds more information than just a pointer. References are _very_
useful, and understanding them is key to becoming an intermediate to
advanced Perl programmer.

A closure is more subtle. It is a reference to an anonymous subroutine
(that is, a subroutine that has been defined with a naked "sub" declaration
and no name), and which refers to one or more lexical ("my") variables that
are declared outside the scope of the subroutine definition. The clever
and magical thing that happens is that the closure "remembers" the values
of those lexical variables, even if they change later. More specifically,
at the time the anonymous subroutine is stored, it gets a private copy of
the lexical variables it references outside its scope. This is rather
useful in some circumstances.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBP2pdNGPeouIeTNHoEQKT8QCgmqPbjHO2OVRb/2oX1vHc1GEiP2AAoI0R
9gItgTctedFY6T9rsourDj2o
=RGc2
-----END PGP SIGNATURE-----

[David McDivitt]

>Subject: Re: referencing, closures, classes

>Date: Fri, 19 Sep 2003 00:12:42 GMT
>
>David McDivitt wrote:
>
>...
>
>

>>
>> 5 use warnings;
>> 6 use strict;
>> 7
>> 8 sub animalInFood
>> 9 {
>> 10 my $x = shift();
>> 11 return sub #what the hell does return sub mean?
>> 12 { #no description given anywhere

>
>
>The "return sub {...}" is returning a code reference to the anonymous
>sub consisting of the code between the braces (see perldoc -f sub to see
>what the sub function does). Bear in mind that when there is no
>semicolon or ending brace, the Perl expression isn't over yet -- it
>continues on subsequent lines. In this case, that anonymous sub is a
>closure because it uses $x, a lexical variable which was already defined
>in the scope of the sub at the time the sub was defined. You will note
>that if you call the returned code reference, it remembers the value of
>the in-scope lexical at the time the sub was defined. There is no magic
>to this, and actually, it barely warrants the special name "closure"
>(which name, as far as I can tell, might as well be any made-up name, as
>the ordinary concept of "closure" seems to bear no relation to this).
>It is simply a matter of the normal behavior of scoped lexical
>variables. Each time "animalInFood" is called, another anonymous code
>reference consisting of a sub with $x already in its scope with the
>value is has at the moment is created. When that code reference is
>executed later, it remembers its $x. That's all there is to it. For
>fun, try writing closures which modify their already-in-scope variables.
>
>

>> 13 my $y = shift();
>> 14 print( "There is a $x in my $y!\n" );
>> 15 };
>> 16 }
>> 17
>> 18 my &$flyInFood = animalInFood( "fly" );
>> 19 my &$frogInFood = animalInFood( "frog" );
>> 20
>> 21 &$flyInFood( "soup" );
>> 22 &$frogInFood( "coffee" );
>>
>> There is a fly in my soup!
>> There is a frog in my coffee!
>> fig 13.8
>>
>> You can see that "animalInFood returns closures because when we assign
>> variable "$flyInFood" the closure returned by passing "animalInFood" the
>> word "fly", then call "animalInFood" again with the value "frog". Each
>> closure is stored in a reference. These references are used at lines 21 and
>> 22 to invoke each closure. Note that the closure invoked at line 21 prints a
>> string containing the word "fly", which was passed to the first call to
>> "animalInFood". Similarly, the closure invoked at line 22 prints a string
>> containing the word "frog", which was passed to the second call to
>> "animalInFood".
>>
>> ********************************
>>
>> I don't know what I'm supposed to get from this. It is not well written in
>> my opinion and I fail to get the point of even reading it. Closures seem to
>> be very important however, and understanding closures would seem to help one
>> understand classes, too. Thanks

>
>
>Well, it seems fairly clear to me, but I do think it would be better to
>describe the phenomenon as simply the expected behavior of scoped
>lexical variables, just exactly like what happens in any other scope. I
>don't know how important they are -- I guess they can be pretty
>important for generating obfuscated code, maybe. And they do let you
>create truly private variables which absolutely nothing can touch other
>than your own methods when you create modules. But that probably isn't
>very important either (hey, someone can just modify the code of your
>module if they really want to, so what did it really gain? Oh, yeah, it
>obfuscated it to the point where they couldn't understand it anyway, so
>maybe it did keep your module private :-).).

The problem I was having was the "return sub" syntax. This is what does the
closure. The syntax is given one time and one time only in the coding
example, but is not described in the book. The author does this often and
that's why his book is bad.

[Eric Schwartz]

David McDivitt <x12code-del@del-yahoo.com> writes:

> The problem I was having was the "return sub" syntax. This is what does the
> closure.

No it's not. Remember, there is no "return sub" syntax. There's
"sub {...}", which declares an anonymous sub, and returns a reference
to it, and 'return <foo>', which returns a value or list of values.
It's the sub {...} declaration which creates the closure; the return
just returns the subref which the sub {...} creates.

> The syntax is given one time and one time only in the coding
> example, but is not described in the book. The author does this often and
> that's why his book is bad.

Among other reasons. Sounds like you need a better book, which the
regulars here have already pointed you towards.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.

[David K. Wall]

Eric Schwartz <emschwar@pobox.com> wrote:

> David McDivitt <x12code-del@del-yahoo.com> writes:

>> The problem I was having was the "return sub" syntax. This is
>> what does the closure.

>
> No it's not. Remember, there is no "return sub" syntax. There's
> "sub {...}", which declares an anonymous sub, and returns a
> reference to it, and 'return <foo>', which returns a value or list
> of values. It's the sub {...} declaration which creates the
> closure; the return just returns the subref which the sub {...}
> creates.

I don't see why anonymous subroutines were used to introduce
closures, anyway. Other than the syntax used to call the subroutine,
what difference does it make whether the subroutine has a name or
not? As Matija Papec pointed out, Damian Conway's _Object Oriented
Perl_ book defines a closure as just a subroutine that refers to one
or more lexical variables declared outside the subroutine itself.
But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
ed), too.

Using anonymous subroutines to *introduce* closures seems like
unnecessary obfuscation to me. Introduce the idea with as few
complications as possible, *then* show how to make them more
powerful.

Or am I missing something?

--
David Wall

[Uri Guttman]

>>>>> "DKW" == David K Wall <usenet@dwall.fastmail.fm> writes:

DKW> I don't see why anonymous subroutines were used to introduce
DKW> closures, anyway. Other than the syntax used to call the subroutine,
DKW> what difference does it make whether the subroutine has a name or
DKW> not? As Matija Papec pointed out, Damian Conway's _Object Oriented
DKW> Perl_ book defines a closure as just a subroutine that refers to one
DKW> or more lexical variables declared outside the subroutine itself.
DKW> But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
DKW> ed), too.

you can't generate multiple closures with named subs. you can only have
one sub with a given name so it is a limiting factor.

{ my $foo = 4 ;

sub bump_foo { return ++$foo}

}

that is a closure by your rule (and many others). i prefer to use the
term where anon subs are used since closures are meant to carry private
data around. the above code really just hides $foo (even if it is
carried by the sub in its pad).

in fact there was a bug report on p5p regarding named closures not being
garbage collected properly whereas anon ones worked fine.

DKW> Using anonymous subroutines to *introduce* closures seems like
DKW> unnecessary obfuscation to me. Introduce the idea with as few
DKW> complications as possible, *then* show how to make them more
DKW> powerful.

DKW> Or am I missing something?

writing a better section on it would be better. you need anon subs to
make closures useful. but you should cover anon subs and code refs first
and later introduce closures. then you teach the stuff incrementally.

as for the 'return sub' syntax, how many times have we seen print <<FOO
and newbies think <<FOO is a part of the print syntax? again, that is
the result of cargo cult learning and bad books.

uri

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]
Damian Conway Class in Boston - Sept 2003 -- [url]http://www.stemsystems.com/class[/url]

[David McDivitt]

>From: "David K. Wall" <usenet@dwall.fastmail.fm>

>Subject: Re: referencing, closures, classes
>Date: Fri, 19 Sep 2003 17:32:09 -0000
>
>Eric Schwartz <emschwar@pobox.com> wrote:
>

>> David McDivitt <x12code-del@del-yahoo.com> writes:

>>> The problem I was having was the "return sub" syntax. This is
>>> what does the closure.

>>
>> No it's not. Remember, there is no "return sub" syntax. There's
>> "sub {...}", which declares an anonymous sub, and returns a
>> reference to it, and 'return <foo>', which returns a value or list
>> of values. It's the sub {...} declaration which creates the
>> closure; the return just returns the subref which the sub {...}
>> creates.

>
>I don't see why anonymous subroutines were used to introduce
>closures, anyway. Other than the syntax used to call the subroutine,
>what difference does it make whether the subroutine has a name or
>not? As Matija Papec pointed out, Damian Conway's _Object Oriented
>Perl_ book defines a closure as just a subroutine that refers to one
>or more lexical variables declared outside the subroutine itself.
>But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
>ed), too.
>
>Using anonymous subroutines to *introduce* closures seems like
>unnecessary obfuscation to me. Introduce the idea with as few
>complications as possible, *then* show how to make them more
>powerful.
>
>Or am I missing something?

I plan on getting that book soon as I've finished the one I have. I
appreciate Eric Roode mentioning it. Being new to the language I don't know
what things are most significant at this point and what I don't need to
worry about, in the context of learning one thing after another. Dialog here
has been helpful. Just as Perl is not a strongly typed language, people seem
less anal retentive about it in general, which is refreshing.

[David McDivitt]

>From: Uri Guttman <uri@stemsystems.com>

>Subject: Re: referencing, closures, classes
>Date: Fri, 19 Sep 2003 17:53:38 GMT
>

>>>>>> "DKW" == David K Wall <usenet@dwall.fastmail.fm> writes:

>
> DKW> I don't see why anonymous subroutines were used to introduce
> DKW> closures, anyway. Other than the syntax used to call the subroutine,
> DKW> what difference does it make whether the subroutine has a name or
> DKW> not? As Matija Papec pointed out, Damian Conway's _Object Oriented
> DKW> Perl_ book defines a closure as just a subroutine that refers to one
> DKW> or more lexical variables declared outside the subroutine itself.
> DKW> But Larry uses anonymous subroutines in the Camel (p 259 in the 3rd
> DKW> ed), too.
>
>you can't generate multiple closures with named subs. you can only have
>one sub with a given name so it is a limiting factor.
>
>{ my $foo = 4 ;
>
>sub bump_foo { return ++$foo}
>
>}
>
>that is a closure by your rule (and many others). i prefer to use the
>term where anon subs are used since closures are meant to carry private
>data around. the above code really just hides $foo (even if it is
>carried by the sub in its pad).
>
>in fact there was a bug report on p5p regarding named closures not being
>garbage collected properly whereas anon ones worked fine.
>
> DKW> Using anonymous subroutines to *introduce* closures seems like
> DKW> unnecessary obfuscation to me. Introduce the idea with as few
> DKW> complications as possible, *then* show how to make them more
> DKW> powerful.
>
> DKW> Or am I missing something?
>
>writing a better section on it would be better. you need anon subs to
>make closures useful. but you should cover anon subs and code refs first
>and later introduce closures. then you teach the stuff incrementally.
>
>as for the 'return sub' syntax, how many times have we seen print <<FOO
>and newbies think <<FOO is a part of the print syntax? again, that is
>the result of cargo cult learning and bad books.

You expressed an excellent point and one I've had a problem with -
recognizing what's significant as I go along. The book is so badly written,
with things seeming significant which are not, I may have to read a portion
several times.

[Uri Guttman]

>>>>> "DM" == David McDivitt <x12code-del@del-yahoo.com> writes:

>> From: Uri Guttman <uri@stemsystems.com>

>> writing a better section on it would be better. you need anon subs to
>> make closures useful. but you should cover anon subs and code refs first
>> and later introduce closures. then you teach the stuff incrementally.
>>
>> as for the 'return sub' syntax, how many times have we seen print <<FOO
>> and newbies think <<FOO is a part of the print syntax? again, that is
>> the result of cargo cult learning and bad books.

DM> You expressed an excellent point and one I've had a problem with -
DM> recognizing what's significant as I go along. The book is so badly
DM> written, with things seeming significant which are not, I may have
DM> to read a portion several times.

so when will you burn this waste of wood pulp and get a better book?

uri

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]
Damian Conway Class in Boston - Sept 2003 -- [url]http://www.stemsystems.com/class[/url]

[Uri Guttman]

>>>>> "DM" == David McDivitt <x12code-del@del-yahoo.com> writes:

DM> I plan on getting that book soon as I've finished the one I
DM> have. I appreciate Eric Roode mentioning it. Being new to the
DM> language I don't know what things are most significant at this
DM> point and what I don't need to worry about, in the context of
DM> learning one thing after another. Dialog here has been
DM> helpful. Just as Perl is not a strongly typed language, people
DM> seem less anal retentive about it in general, which is refreshing.

you'd be better off dropping that book altogether and getting
others. you keep mentioning its weaknesses and no strengths so why keep
reading it? and closures are not something to teach early or so lightly.

uri

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]
Damian Conway Class in Boston - Sept 2003 -- [url]http://www.stemsystems.com/class[/url]

[Matija Papec]

X-Ftn-To: David McDivitt

David McDivitt <x12code-del@del-yahoo.com> wrote:

>Here is what the book says:

<snip>

>string containing the word "fly", which was passed to the first call to
>"animalInFood". Similarly, the closure invoked at line 22 prints a string
>containing the word "frog", which was passed to the second call to
>"animalInFood".
>********************************
>
>I don't know what I'm supposed to get from this. It is not well written in
>my opinion and I fail to get the point of even reading it. Closures seem to
>be very important however, and understanding closures would seem to help one
>understand classes, too. Thanks

Nope, closures have nothing to do with classes, moreover they are not
crucial for understanding an OO paradigm. However, they are usually
portrayed as possible choice for object currier(in practice hashes are far
often used).
So, for what on the earth are they useful? Closures offer complete data
encapsulation so you can't directly change object attributes like with
hashrefs,

use SomeClass;
my $object = SomeClass->new;
#access via hash reference
$object->{attribute} = 'Breaking the law!';

There is an excelent book on OO Perl writen by Damian Conway where you can
dive in all object details(IMO, best thing beside "Perl Cookbook").


--
Matija

[David McDivitt]

Pretty quick!

>From: Uri Guttman <uri@stemsystems.com>
>Subject: Re: referencing, closures, classes
>Date: Fri, 19 Sep 2003 19:54:36 GMT
>

>>>>>> "DM" == David McDivitt <x12code-del@del-yahoo.com> writes:

>

> >> From: Uri Guttman <uri@stemsystems.com>

>

> >> writing a better section on it would be better. you need anon subs to
> >> make closures useful. but you should cover anon subs and code refs first
> >> and later introduce closures. then you teach the stuff incrementally.
> >>
> >> as for the 'return sub' syntax, how many times have we seen print <<FOO
> >> and newbies think <<FOO is a part of the print syntax? again, that is
> >> the result of cargo cult learning and bad books.

>
> DM> You expressed an excellent point and one I've had a problem with -
> DM> recognizing what's significant as I go along. The book is so badly
> DM> written, with things seeming significant which are not, I may have
> DM> to read a portion several times.
>
>so when will you burn this waste of wood pulp and get a better book?

[David McDivitt]

>From: Uri Guttman <uri@stemsystems.com>

>Subject: Re: referencing, closures, classes
>Date: Fri, 19 Sep 2003 19:56:09 GMT
>

>>>>>> "DM" == David McDivitt <x12code-del@del-yahoo.com> writes:

>
> DM> I plan on getting that book soon as I've finished the one I
> DM> have. I appreciate Eric Roode mentioning it. Being new to the
> DM> language I don't know what things are most significant at this
> DM> point and what I don't need to worry about, in the context of
> DM> learning one thing after another. Dialog here has been
> DM> helpful. Just as Perl is not a strongly typed language, people
> DM> seem less anal retentive about it in general, which is refreshing.
>
>you'd be better off dropping that book altogether and getting
>others. you keep mentioning its weaknesses and no strengths so why keep
>reading it? and closures are not something to teach early or so lightly.

The closure part was brief. Classes weren't too bad. The rest of the book
looks like gravy. Databases, threads, etc. I spent $85 on the book. Too
much, yes, but I wanted something immediately. Why were there not many Perl
books at Barnes and Noble?

The book does have good stuff such as a whole chapter on fundamental flow
charting. It was not UML. I hate stick people. There as another good chapter
on the history of computers and the internet. The book is not a total waste.