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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
How unexpected. (Score:1)
If you don't like *::Tiny, don't use them. If you think they suck, submit a patch. If *::Tiny does what you need, without installed 42 other modules, (most of which in the XML namespace have various levels of compile headaches and lib versioning issues) then awesome.
Really, what's the big deal again? It feels like quibbling about calling a non-pedigree cat a feline just because it's not a purebred.
Re: (Score:1)
CPAN names are rare. They're first-come, first-served. Thus it seems rude to me to claim a namespace for a distribution that doesn't actually do what the name claims.
There's tremendous potential for confusion among the vast majority of CPAN users who've never read use Perl. That seems, to me, highly unfair.
I'm also much less of a fan of bandying about strong assertions such as "Oh yeah, well no real user ever really uses this feature or that feature" without some
Re: (Score:1)
I don't necessarily disagree with your overall naming issues. But if DBI and XML namespaces are so precious, they should be locked down, and registered to the appropriate set of users. But since we don't register namespaces any more on CPAN, game on as it seems.
Re: (Score:1)
Perhaps it does in the sense that what it parses bears a superficial resemblance to XML, in the same way that what
PPI::Tinyparses bears a very superficial resemblance to whatPPIparses.XML has a widely-distributed, well-understood, and well-implemented specification. It's easy to test a parser for compliance with the specification. If it fails, it's not an XML parser.
That was the point of specifying XML.
XML::Tinydeliberately does not implement thRe: (Score:1)
Hardly. It bears more of a resemblence to String.pm
NONE of the Tiny modules are in compliance with the standards they implement, and all of them make quite clear that they are for a very specific use case, and you should move to a real module as soon as it doesn't meet your needs.
And the argument of implementing something DIFFERENT, as opposed to implementing something incompletely, is a complete straw man argument.
Re: (Score:1)
Without a specification, I can't see how anyone can decide what is and isn't PPI. I chose the example pretty carefully.
YAML::Tinydoesn't parse YAML. That is, I can give it a valid YAML document--perfectly valid, according to the YAML specification--and the module will fail to parse it appropriately. The documentation makes it very clear that you aren't interested in parsing YAML. That's fine, but it makes me wonder why YAML is in the name of the distriRe: (Score:1)
> YAML::Tiny doesn't parse YAML. That is, I can give it a valid YAML document--perfectly valid, according to the YAML specification--and the module will fail to parse it appropriately
That's not entirely correct.
If you give it a set of YAML documents, it will
Re:How unexpected. (Score:2)
Reply to This
Parent