NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
help them think they understand.
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
only inasmuch as There's Only One Way To Do It (Score:1)
Abstractions incur overhead, yep. Fortunately, POE's higher-level abstractions (wheels, components) are entirely optional. The low-level abstract event loop primitives are still there: select_read(), alarm(), sig(), etc. There's a smaller POE inside. It's already out, but it's been a bit neglected.
History has a bigger role to play than abstractions in the obstruction of change. A long-established, stable module like P
Re:only inasmuch as There's Only One Way To Do It (Score:1)
The context I was talking about POE in was this: a program written to use it versus one written to do something else looks very different. This means that it's hard to switch styles. A lot of changes have to happen to a lot of the program.
Everything goes out of fashion eventually.
That was part of the point of evaluating how entrenched any abstraction will make you. Being entrenched by an abstraction is a mark against it.
Too much and leaky abstraction is another matter and I whipped on other things there.
I'm also talking about the style of POE people tend to write in.
I'm sorry that POE had to be the example of this one consideration.
-scott
Reply to This
Parent