|Do you know where your variables are?|
Re^4: IO::File vs CORE::openby EvanCarroll (Chaplain)
|on May 13, 2009 at 03:39 UTC||Need Help??|
I'd rather demonstrate with code:
The above code is fairly normal perl: each package is prefixed with the modules it requires. Now, watch:
The above code is fairly normal perl: each package is prefixed with the modules it requires. Except it doesn't work, this time around extra knowledge of the internal implementation of an edge case of a CORE function is required.
So, you're totally off here, while IO::File requires IO::File to be loaded this is expected; CORE::open requiring IO::Handle, is not. As for Win32::Process::Create, congrats you found one. For the others, they are all just as awkward. Another awkward complexity perl programmers have to learn with questionable-to-0 gain. I would argue here that my/local/state don't apply to this argument.
Subclassing something that isn't an object is awkward... You don't say! What does that even mean.Is it or isn't it? You seem to disagree with some of the other people that defend it. It accepts method calls, it delegates to a class, and it has a ->new. If it walks like an object (with a broken leg), and talks like an object (with a speech impediment) in perl -- it's obviously a stupid hackish-object.
Inheritance isn't the best choice for files anyway, whether using IO::File or not.Inheritance works fine for my needs to extend a fh -- ( i had to add whether the file was created on the call to create a write filehandle, and cache the name the file was opened from ).
It isn't about critiquing CORE::open for it's weirdness, it about showing people you don't need to work with archaic weird idioms when learning perl. Just tell them to use IO::File and enjoy that at least some of the weirdness will be absent. I prefer to omit the esoteric features of perl, and I'm arguing that CORE::open here is esoteric, non-transparent, and hackish in comparison to the IO::File's version