Is IO::String a core module of 5.8, no, at least not with active state perl 5.8.0.
From 5.8's perlfunc:
File handles can be opened to "in memory" files
held in Perl scalars via:
open($fh, `>', \$variable) || ..
Sorry. I misread somewhere that this had been implemented by putting IO::String in the core, but apparently it's a reimplementation as PerlIO::scalar.
why you suddenly turned this into personal attack
I didn't turn this into a personal attack. Apparently, you haven't read my standard disclaimer, as indicated in the footer of every recent message.
This isn't about you, as much as you might think it is. It's about ending behavior that is overall damaging to the community. When I have opinions about that, I speak them. It's certainly fair for you to comment about my opinions, but I notice you didn't actually challenge them. I would welcome that.
I would welcome your exchange about how reinventing a wheel and needlessly forking a good solution into two solutions, one of which has a limited use (yours) and the other is built from standard CPAN parts can be of benefit to the community. Instead, it seems like something that is harmful to me. And when something seems harmful, I am quick to raise the flag.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply. | [reply]
[d/l] |
I disagree that it's damaging to the community. While I agree with your advice to use IO::String,
I think you are way off base telling him to keep his code to himself.
What teaches you more? Typing a use statement or solving a problem?
Should we not know how to make a fire because we have lighters?
Furthermore, other people viewing such problems and solutions can learn from the experience as well about the way to do or not to do things.
There are numerous problems that are neatly solved with CPAN but it doesn't teach most people anything at all.
(Though it certainly makes them more productive)
It's not like there are code reviews here of modules that might expose users to the how and why of the way things are, or should be done.
If you don't feel like helping someone reinvent a wheel that's your prerogative but you have no right to tell
someone to keep it to themselves because while you contribute more than most,
it isn't your community but "our" community, and communities have a way of sorting these issues out all on their own.
Now if the discussion here was about submitting this to CPAN, then that would be a different issue. Though given different but equally well implemented ends to the same means, my preference is for all of them to be available.
There are reasons certain things get done over and over. Part of this of course is just to say you did, but often it's because the implementation
disagrees with a potential users perspective of how the problem should be solved. I tend to think of writing code as writing any literature. People have their own perspective that shapes the work.
If my perspective is different, should I do it your way because you did it first? Looking at problems from different perspectives is what got us out of the stone age.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
You apparently have not had to deal with the amount of cargo cult crap that I have. I suspect that when you have, you'll change your tune.
Any posting becomes a potential meme. We can't afford to create more Matt Wrights out there. That's my point.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
| [reply] |
| [reply] |
| [reply] |