* Mark Overmeer <[EMAIL PROTECTED]> [2008-12-07 14:20]: > > > - you have XML-files with meta-data on files which are > > > being distributed. (I have a lot of those) > > Use URI encoding unless you like a world of pain. > > You are looking at it from the wrong point of view: Perl is > used as a glue language: other people determine what kind of > data we have to process. So, also in my case, the content of > these XML structures is totally out of my hands: no influence > on the definitions at all. I think that is the more common > situation.
If you start with a broken data format, no amount of papering over it will unbreak it. Sorry, Perl 6 won’t have magic ponies to fix that. Ambiguous data cannot be disambiguated by smart code. If you want to try anyway, talk to someone who didn’t get their name on an IETF RFC out of disgust with the state of an unfixably messy legacy data format. > > NTFS seems to say it’s all Unicode and comes back as either > > CP1252 or UTF-16 depending on which API you use, so I guess > > you could auto-decode those. But FAT is codepage-dependent, > > and I don’t know if Windows has a good way of distinguishing > > when you are getting what. So Windows seems marginally more > > consistent than Unix, but possibly only apparently. (What > > happens if you zip a file with random binary garbage for a > > name on Unix and then unzip it on Windows?) > > > > I have no idea what other systems do. > > Well, the nice thing about File::Spec/Class::Path is that > someone did know how those systems work and everyone can > benefit from it. These modules are completely and utterly oblivious to encoding issues, so I have no idea how they are relevant in the first place. > So why are you all so hessitating in making each other's life > easier? There is no 100% solution, but 0% is even worse! Because I have seen Java, and it taught me that the 90% solution is worse than the 20% solution. Provide 20% in the language and someone will use that and write Path::Class. And if we abstain from putting today’s best solutions in the core library, then we have a chance that tomorrow’s best solutions might gain traction. (Otherwise we get 10 years of CGI.pm again.) > Once upon a time, Perl people where eager for good DWIMming and > powerful programming. And yet it’s the CPAN that turned out to be Perl’s greatest strength. If you suggested the initial concept of the CPAN today, people would laugh at you – it would seem like an April fool’s joke. It didn’t even have a standard package format! > Nowadays, I see so much fear in our community to attempt > simpler/better/other ways of programming. Simpler in what way? All abstractions leak. Take this into account or make users suffer. > We get a brand new language, with a horribly outdated > documentation system and very traditional OS approach. As if > everyone prefers to stick to Perl's 22 years and Unixes 39 > years old choices, where the world around us saw huge > development and change in needs. If you can show me a ubiquitous kernel that runs perl and was designed less than 15 years ago, I’ll show you a modern OS API approach. If you want to see an attempt at an abstract interface layered over crusty OS designs, I’ll show you Java. Abstaining from the attractive nuisance of abstracting small- seeming differences away seems to have worked out well enough for DBI, anyway. Would you argue that DBI is not a good or relevant example? (And if so, why?) Or are you suggesting that approach was a failure or horrible in some way? > Are "we" just getting old, grumpy and tired? Where is the new > blood to stir us up? Busy designing their own second system. You want to invite a bunch of PHP kids? I’m game. :-) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
