On Fri, 5 Dec 2008 18:30:27 +0000, David Cantrell wrote:
> Peter Haworth wrote:
> > David Cantrell tried to convince the masses that closures are actually
> > simple, and extremely useful. His view is that they are basically
> > code with data attached; the inverse of objects, which are data with
> > code attached. He also made a good analogy between the class/object
> > distinction and the sub/closure distinction. Unfortunately, the example
> > from CPU::Emulator::Z80 focussed too much on the details of z80 emulation,
> > and not enough on the benefits gained by using closures.
>
> How about I edit it to talk about generic 8- and 16-bit data types early
> on, and how the closures allow the sorts of access I need, and then show
> how it applies to the emulator, refactoring etc?
I think the problem is that there is too much explanation required of the
problem, because most of the audience is never going to usea z80 emulator,
much less need to write one themselves. The application of closures to this
problem isn't a bad solution; I just don't think it makes for a good
illustration, unless your audience is mostly made up of people who care
deeply about such things. Speaking of which, everyone needs to sort...
> > example from Sort::MultipleFields was more lucid, but a diagram would
> > have been a big help to anyone who can't convert from unfamiliar code
> > to data structures in their head.
>
> I'm not sure that a diagram would help, cos it's not really creating a
> data structure, but perhaps I could take the example of sorting books by
> author/title/year/spine colour, and as I explain how it builds up the
> closurey sort function, show a *non*-closurey equivalent being built up
> next to it.
Because you're building up a chain of closures, and can easily get away
with just one in the simplest case, I think this would make a much better
first example than the emulator, especially if shown as a progression:
Step 1: single comparison, order is just 'asc'/'desc'
my $sortsub=mksort(author => 'asc');
@sorted=sort $sortsub @unsorted; # Prototype makes $a & $b redundant
sub mksort{
my($field,$spec)[EMAIL PROTECTED];
if($spec=~/\Aasc(?:ending)?\z/i){
return sub($$){ $_[0]{$field} cmp $_[1]{$field} };
}else{
return sub($$){ $_[1]{$field} cmp $_[0]{$field} };
}
}
$sortsub=/--------------------------------------------\
| sub($$){ $_[0]{$field} cmp $_[1]{$field} } |
+--------------------------------------------+
| $field='author' |
\--------------------------------------------/
Step 2: multiple comparisons
my $sortsub=mksort(author => 'asc',year => 'desc');
@sorted=sort $sortsub @unsorted;
sub mksort{
my $sort=sub($$){ 0; };
while(@_){
my($field,$spec)=splice @_,-2;
my $newsub=$spec=~/\Aasc(?:ending)?\z/i
? sub($$){ $_[0]{$field} cmp $_[1]{$field} || $sort->(@_) }
: sub($$){ $_[1]{$field} cmp $_[0]{$field} || $sort->(@_) }
;
$sort=$newsub;
}
return $sort;
}
$sortsub=
/----------------------------------------------------------------------\
| sub($$){ $_[0]{field} cmp $_[1]{$field} || $sort->(@_) } | |
+----------------------------------------------------------------------+
| $field='author' |
| $sort= /-----------------------------------------------------------\ |
| | sub($$){ $_[1]{$field} cmp $_[0]{$field} || $sort->(@_) } | |
| +-----------------------------------------------------------+ |
| | $field='year' | |
| | $sort= /--------------\ | |
| | | sub($$){ 0 } | | |
| | \--------------/ | |
| \-----------------------------------------------------------/ |
\----------------------------------------------------------------------/
Final step: factored $spec, allowing for complex comparisons, plus the
segfault protection. This is essentially the same as your lone SMF example.
I could be wrong, but I think the diagrams make it clearer what's actually
being closed over, and why that's a benefit.
> And thankyou - constructive criticism is *most* useful!
You're welcome. I know that most of my presentations could have used some.
--
Peter Haworth [EMAIL PROTECTED]
"Ooops, awfully sorry about that [typo].
I must change my fingers to a narrower, sportier model."
-- Jarkko Hietaniemi
_______________________________________________
BristolBathPM mailing list
[email protected]
http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
