in reply to Re^7: Correct syntax for using $INC to keep modules in same file
in thread can't import using exporter
Nonsense.Really? Show me how I can have 'use' default to NOT searching for something without me poking into perl internals like $::INC{magic_name_change(A::B::C)=1};.
Historically we didn't have computers, so none of your arguments regarding "established perl behavior" hold water. Things CHANGE. Just because perl did something a certain way in the past, doesn't mean it HAS to do it in the future.
Defaulting to full UTF-8 compatibility is very possible. The idea that all new products must remain backward compatible with things created 20 years ago is ludicrous and a way to extinction.
Microsoft *tried*, and they have alot more money and resources than perl does -- and they failed.
Many things have been ***deprecated*** then removed or changed. Demanding that the perl remain Anglo-centric and default to the English languages' 8-bit charset LATIN-1 (or more specifically ISO-8859-1), is incredibly selfish and short-sighted. I can't believe how Anglo-Centric this list is - that you don't care about other countries or other language -- and what's your excuse for things remaining broken?
Compatibility with programs written when 640K was considered good enough for any program... (or close to it). That's insane!
5.8.0 did it wrong -- they didn't go through a use 'feature' stage, or a deprecation stage...they just shifted things to utf-8, which still is hard to believe -- that they didn't even check the users locale or environment like every other user-interactive program. Why would perl do that? Now everyone is gunshy about doing the right thing.
If you want your 10-20 year old program to keep running, then keep your perl that you wrote it with. Don't expect that there won't be deprecations -- because there has been and there will be. To argue against change is to argue against life in multiple senses, but most of all, the life of the language. If you freeze it, you'll end up with Cobol. There isn't one language in use today that hasn't been revised if it is > a decade (probably > 3-5 years) old.
I'm not interested in helping you if you're going to put strawmen arguments in my mouth.Huh?... I simply listed code that works... I didn't ask for help on this subthread. The code works very well. As I run it on more examples, I will probably find more things I need to account for, but at least it's in a modular format with separate classes for different functions that I can choose to replace or split out at will.
And I am splitting out commonly used modules... (got complaints about that when someone couldn't get my code to run because my module wasn't in CPAN.
So let me ask you -- you think CPAN is going to accept my modules? -- things like 'mem' which are completely empty of code (and take 1 line to code inline). Unlikely.
So if I want to use modular code, I don't have a choice but to put it all in 1 file -- as its very unlikely my code would be accepted into CPAN.
So how are you going to help that? Tell me to completely change the way I program? To program like some mindless drone? My time is too limited.
Download which examples... are you talking about all the ones I tried that don't work, or the one I posted that works? I'm 98% sure the one written in all BEGIN's will work, as that's pretty much the only thing 'use mem' does (a sub for BEGIN).
Since I'm writing most of my headers twice or in BEGINS now, how can you say I am not listening to any of the advice on here? That's exactly the 1 completely working test case that was posted.
That I'm doing it in my own way, and not verbatim copying, is that your issue?
How can you say I didn't end up doing it almost exactly the way, I think it was Corian, demonstrated? Think about it functionally rather than by form and name. I'm using BEGIN all over the place to get around the problems I earlier had. So can you be a bit more precise about what it is that you are trying to fix (since this program works), or what example I should or shouldn't be following, since functionally, I'm basically using Corian's technique of forcing half my definitions or more into BEGIN blocks.
What is your beef? The fact that I want perl to process unicode as well as any other console text program? Gosh, how evil I am...
Even the writeups about how perl can't handle UTF-8 in source are ridiculous... All Perl needs to do is call 'file <source>', and it will tell perl what encoding to use. I mean if it can do it, and perl can't, then just call it and use it's results.