Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Federico Lucifredi continues his quest to build a hardware-assisted
automagic hard-drive wiper, using perl in an embedded device. *Shiny
hardware! Demo! Code*!
Federico,
It was getting late, so I didn't want to throw in another
tangent for how to write your code. But I was thinking you
could replace your printline() function with a closure.
Instead of doing this over and over:
printline($var1,\$y,text,font,$size);
You could take $y and put it inside a lexical block
then make a printline closure that uses $y
(basically, it's a global tothe subroutine, but the
lexical block means no one outside the block can
see $y or muck with it.
Then you don't have to keep passing in \$y every call.
The second, minor bit, is to reorder your parameters
a bit so that the things that change the most are first,
and the things that are usually one value are last.
Then you can take advantage of default values.
The code might look something like this:
# using dummy stubs, cause I don't remember how your code
# came up with these values
sub calculate_initial_value{return 4;}
sub offset_value{return 8;}
my $printline;
{ # lexical scope hides $y from everyone outside the scope.
my $y = calculate_initial_value();
$printline = sub{
my($text,$size,$font)=@_;
$size||=8;# default value
$font||=normal; # default value;
$y=$y+offset_value();
print text is '$text', size is '$size', font is '$font', y is '$y'\n;
};
} # end lexical scope
#Now call the closure, and you don't have ot pass in $y
#and you don't have to pass in default values
$printline-(hello);
$printline-(world, 6);
$printline-(Bye, 4, bold);
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Greg London wrote:
...replace your printline() function with a closure.
Instead of doing this over and over:
printline($var1,\$y,text,font,$size);
You could take $y and put it inside a lexical block...
To me this looks like an example of where we suffer by not having OO
truly baked into the language. It's a pretty natural fit for this
problem, but not the first thing people shout out, because we tend to
want to keep small scripts simple and procedural, and not bother with
the overhead of OO.
package Thermal::Printer;
sub new {
...
if (!$args{context})
my $surface = Cairo::ImageSurface-create(...);
$args{context} = Cairo::Context-create($surface);
}
...
}
...
package main;
my $printer = Thermal::Printer-new(
font = $font, # default
size = $size, # default
);
...
$printer-write($text);
$printer-font($other_font)-size($other_size)-write($more_text);
...
That particular example has font and size as object attributes, which
you can update to alter from their initial condition, and then they'll
persist with the new value until altered again. Alternatively you could do:
$printer-write($text, font = $other_font, size = $other_size);
to override defaults for just that one write() call. Both options could
be implemented without conflict.
The OO approach gives you a cleaner syntax, and keeps all the internal
housekeeping details (context, position) hidden within the object.
my($text,$size,$font)=@_;
Federico mentioned dislike of the subroutine argument declaration in
Perl. How about:
http://search.cpan.org/~noirin/perl5i-v2.11.2/lib/perl5i.pm#Subroutine_and_Method_Signatures
or:
http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/Devel/Declare.pm
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
Enterprise solutions through open source.
Professional Profile: http://tmetro.venturelogic.com/
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Greg London wrote:
...replace your printline() function with a closure.
Instead of doing this over and over:
printline($var1,\$y,text,font,$size);
You could take $y and put it inside a lexical block...
To me this looks like an example of where we suffer by not having OO
truly baked into the language. It's a pretty natural fit for this
problem, but not the first thing people shout out, because we tend to
want to keep small scripts simple and procedural, and not bother with
the overhead of OO.
Meh. I don't blame that on perl's lack of builtin OO.
I've pasted an OO version and the closure version of my script below.
They're nearly identical. they both take about the same amount of
lines of code. Perl's bolt-on version of classes can fix this
about as easily as perl's closure stuff can fix it.
The problem is I'm not thinking of this script as an OO script.
I suppose one could imagine a class call HD_Label and every
object is a specific label, but I'm not entirely convinced that
that would actually be an improvement.
Given how short the script is, I wasn't even really worried about
$y being passed in by reference every call to printline.
Federico pointed it out as something that annoyed him.
I solved that particular problem with minimal modification to the
rest of his code.
If this were a much larger script, I might suggest rearchitecthing
it from the ground up, converting it from procedural to object
oriented, but it was short enough that I shrugged it off.
What I was left with at the end of the evening was that wiping
a drive this way isn't really secure for data you care about.
It would seem that a drill press with a large bit to drill
a couple holes in the platter at different radii, and
then drill a hole right through the bearing so it can't spin
without grinding, would be the better solution.
So, the printline( \$y thingy was more a minor afterthought in my mind.
Greg
Here is the OO version:
{
package printline;
sub calculate_initial_value{return 4;}
sub offset_value{return 8;}
sub new{
my $obj={
yval=calculate_initial_value(),
};
return bless($obj,'printline');
}
sub print{
my $obj=shift(@_);
my($text,$size,$font)=@_;
$size||=8;
$font||=normal; # default value;
$obj-{yval}+=offset_value();
print text is '$text', size is '$size', font is '$font', y is '.
($obj-{yval}). '\n;
};
}
my $pl = printline-new();
$pl-print(hello);
$pl-print(world, 6);
$pl-print(world, 4, bold);
Here is the closure version:
sub calculate_initial_value{return 4;}
sub offset_value{return 8;}
my $printline;
{
my $y = calculate_initial_value();
$printline = sub{
my($text,$size,$font)=@_;
$size||=8;
$font||=normal; # default value;
$y=$y+offset_value();
print text is '$text', size is '$size', font is '$font', y is '$y'\n;
};
}
$printline-(hello);
$printline-(world, 6);
$printline-(world, 4, bold);
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Greg London wrote: I've pasted an OO version and the closure version of my script below. They're nearly identical. they both take about the same amount of lines of code. Nice that you fleshed out the examples a bit further. Meh. I don't blame that on perl's lack of builtin OO. The problem is I'm not thinking of this script as an OO script. Given how short the script is... But that's my point. The default, especially with a short script, becomes procedural. I certainly don't advocate dogmatic use of OO. There are lots of cases where procedural stuff is more appropriate. It just seems that we naturally gravitate to procedural in Perl, until we hit some threshold, and then say, oh, I ought to be using OO for this. In other languages, where OO is fully integrated, you start out thinking in OO terms, and then possibly simplify to procedural, if that's what really works best for the problem. Never underestimate the impact of convenience - even if the differences are subtle - on what a person will choose when weighing options. Perl's bolt-on version of classes can fix this about as easily as perl's closure stuff can fix it. The closure version doesn't scale. You can't stick it in a library and call it from multiple places without stepping on things. The natural response is, well that doesn't matter for this trivial use case. But if the coding effort is about the same either way, then why not write it in the first place in a way that could easily be cut-and-pasted into its own library later? It's because of the impression (at least for those of us coding Perl since the 80's) that there is extra effort required for the OO approach, even if in actuality, as you demonstrated, there isn't much difference at all. -Tom -- Tom Metro Venture Logic, Newton, MA, USA Enterprise solutions through open source. Professional Profile: http://tmetro.venturelogic.com/ ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
On Wed, Apr 10, 2013 at 1:33 PM, Tom Metro tmetro+boston...@gmail.com wrote: Greg London wrote: [...] Perl's bolt-on version of classes can fix this about as easily as perl's closure stuff can fix it. The closure version doesn't scale. You can't stick it in a library and call it from multiple places without stepping on things. I do not agree with this assertion. I've seen closure based solutions and OO versions both scale, and both fail. They are appropriate for different problems, and different designs. But as long as you know what they are (and aren't) good at, you can choose either. Speaking personally, I tend to prefer code that is heavy on closures to code that is heavy on OO. But that's a matter of taste. [...] ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
But that's my point. The default, especially with a short script, becomes procedural. Well, I assume it varies from person to person, and the reason my default is procedural is because I've got about two decades of procedural programming under my belt, and only 5 or 10 of the last years has some smattering of OO laid over it. It's what I'm familiar with. I assume kids these days growing up on a plethora of object oriented languages will have more tendancy to come up with OO solutions. Because they're familiar with it. One could probably argue that my choice of perl may be unduly influenced more by the fact that I know perl and less by whether or not perl itself is actually the best language for the problem I'm looking to solve. My default, for almost anything that doesn't have a specific language requirement is to use perl. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
I do not agree with this assertion. I've seen closure based solutions
and OO versions both scale, and both fail. They are appropriate for
different problems, and different designs. But as long as you know
what they are (and aren't) good at, you can choose either.
I'd agree. I've done quite a few closure constructors like this myself:
sub constructor {
my($name,$count)=@_;
my $closure=sub{
$count++;
print incremented $name to $count\n;
};
return $closure;
}
This sort of thing returns a variable that acts like an object
as far as I'm concerned. And it has zero linguistic overhead.
To do that in a class, you have to have a lexical container
or put it in a separate file. declare the package. create a
constructor subroutine, bless it, and create a incrementor
method/subroutine.
{
package increment;
sub new{ return bless({Name=shift(@_),count=shift(@_)}), 'increment'); }
sub inc{ my $obj=shift(@_); $obj-{count}++;
print incremented .($obj-{Name}). to .($obj-{count}.\n;
}
}
that's kinda clunky. It's a lot of line noise.
If perl had more high minded classes, Im not sure how it would look.
{
package increment;
use Moose;
has $name;
has $count;
sub inc{
# I don't use moose, making htis up:
$self=shift(@_);
$self-count() = $self-count() + 1;
print incremented .($self-name()). to .($self-count()).\n;
}
}
I gotta say, the Moose.pm documentation started in second gear
and stripped my clutch.
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Checked my calendar. I'll be there. Greg Have a speaker, one RSVP, and me so far. Who else is coming? On Sun, Apr 7, 2013 at 5:13 PM, Bill Ricker bill.n1...@gmail.com wrote: *Tuesday, April 9, 2013, MIT E51-376 7pm-10pm* Embedded Perl with Federico Federico Lucifredi continues his quest to build a hardware-assisted automagic hard-drive wiper, using perl in an embedded device. *Shiny hardware! Demo! Code*! Location MIT E51-376 (MITDirectionshttp://boston.pm.org/kwiki/index.cgi?MITDirections) Talk begins at 7:30. Refreshments in the hallway prior. *note* back in room E51-37*6* this term. -- please RSVP for refreshments. Our WIKI http://boston.pm.org/kwiki/ * Tech Meetings are held on the 2nd Tuesday of every month at MIT (directions http://boston.pm.org/kwiki/index.cgi?MITDirections ). o NOTE - Sometimes the lot has filled early, overflow is to Hayward lots (avoid MEDICAL RESERVED spaces!). See alternatives http://boston.pm.org/kwiki/index.cgi?MITDirections RSVP for count encouraged but not required, to bill.n1...@gmail.commebill.n1...@gmail.com or Boston-PM list, by 3pm Tuesday. -- Bill @n1vux bill.n1...@gmail.com ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm -- ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday Apr 9th, Embedded Perl with Federico, 7, MIT E51-376
Bill Ricker wrote: Who else is coming? please RSVP for refreshments. I plan to. (But don't add me to the refreshment count.) I'll forward the announcement to the BLU Hardware Hacking list: http://blu.wikispaces.com/Hardware+Hacking where there should be an overlap of interest. -Tom -- Tom Metro Venture Logic, Newton, MA, USA Enterprise solutions through open source. Professional Profile: http://tmetro.venturelogic.com/ ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
