POE is event driven. Wait. What does that mean? To draw a somewhat relevant analogy... For most geeks, life is event driven. Most of the day is spent waiting for something interesting to happen.
Ponder a friday evening. We're talking about a geek here so not much is going on. Just bad american tv. (is there any other kind of american tv?) Delivery Pizza arrives. This causes the geek to scramble for cash, pay the delivery man, and then hungrily devour pizza. When the pizza is gone, the geek resumes watching tv.
The arrival of the pizza is an event. This causes a Pizza Arrival state, the collection of actions including paying for the pizza and eating it. When the Pizza Arrival state ends, the geek goes back to a passive wait state, waiting for the next event in his/her life.
while I'm a fairly proactive coder, choosing to fill my idle times with yet more constructive coding, the past few weeks have felt remarkably event driven... in a bad way.
"Users of Apple Computer Inc.'s Macintosh computers have long enjoyed the technology equivalent of a safe neighborhood, where the viruses and security nuisances that bedevil far more common Windows PCs are practically nonexistent."
not being a current mac (or windows) user, I found this statement kinda funny - does nobody but me remember the early days of mac proliferation in academia where viruses were everywhere? for me, it was late high school and all through college, and disk after disk was hit with one virus or another, and one paper after another lost and needed to be rewritten, so eventually you needed to make space for one anti-virus program after another to combat it all (and remember, you needed to carry around your own boot and software disks, since only one mac in the lab had a hard drive, but the little ambulance icons were cute), and disks were $5.00 and that was a lot of money to a college student...
anyway, for the sake of mac users everywhere, I'm glad to hear that recent mac users haven't been plagued with these problems. or maybe college was a lot longer ago than it feels...
Devel::Cover rocks.PREFIX or use lib to manage local installs on a hosted machine, for example - so I gave him a few pointers along the way, in addition to fixing my module so it worked for him. in truth, I really didn't do much, and I was kinda embarrassed that it took two iterations to fix the problem. but it's all in a day's work for most of us here in the open source world, right?>>0.05 just uploaded to CPAN, and should appear around the world tomorrow.
>>
>>sorry it took so much effort to get this working for you...
>
> Please, no apologies. Thank you so much, you've been more responsive and
> helpful that I ever imagined.
I think I'm a little sad that the default user state is that they think they'll be alone when using code from CPAN or other open source projects.
my $foo = bar();
I think it makes sense, since the definition of bar() might get shuffled in larger codebases so just using the bareword might fail to compile someday.
for method calls, however, I'm completely unconvinced. I don't see how
my $foo = $obj->bar;
is any less clear than
my $foo = $obj->bar();
but perl has lots of little easter eggs that even the best of us don't know, so I ask: in this case can
$obj->bar
ever mean anything different than
$obj->bar()
? and I don't mean for cases where you need to pass in arguments() is required and tricky, like
my $foo = $cv->();
I mean, in all seriousness, exactly how does () add clarity to a method call? what else could you possibly expect ->bar to represent?
maybe it's the difference between
$obj->bar
and
$obj->{bar}
? if so, I don't buy it
Apache::TestConfigParrot and Apache::TestRunParrot to Apache-Test yesterday. what this means is that if you addt/response/TestFoo/bar.pir
to your tests you're now good to go. well, so long as bar.pir spits out TAP.
for the moment this is only really useful for testing mod_parrot itself, but who knows...