Re^3: Improving your skills by reading module sources

[BrowserUk]

misusing Perls OO system

Such an emotive, subjective and utterly meaningless criteria to apply a metric to.

He wrote (writes?) practical, pragmatic, relatively efficient, well-structured modules, with well thought out interfaces that work, across many platforms, and continue to work a decade or so later.

And those things are far more important to me, and to the thousands of general users of his modules, than any airey-fairy, nancy-wancy theoretical 'not-good-OO' or academic O'Woe critiques.

By all means, be the one(*) to re-write IO::Handle or IO::Socket::* using the latest greatest OO framework. And when you're done 3 years from now and you have a mess of OO-spagetti, it'll be 10x as big, take 20x as long to load and run half as fast. And no-one will use it.

The difference between good and bad OO is not whether it performs all internal attribute accesses through setters and getters in order to more easily accommodate the wholesale change of the internal data representation that will never happen. It is: is the interface clean; and: does it work in an efficient manner.

The whole point of abstraction is to hide the difficult stuff behind simple, clean interfaces. So that the module writer can use his knowledge and expertise to best effect, and the user can benefit from that expertise without having to become an expert.

Barr's module do exactly that.

[JavaFan]

Uhm, IO::Handle is just a bunch of methods that allows one to write $handle->func(args) instead of func $handle, args, with func being a core function. Many of its methods are of the form:

sub core_function {
    ... Check number of arguments ...
    core_function($_[0], $_[1], $_[2]);
}

The objects are blessed handles, not the most convenient things if you want to subclass and actually store attributes, unless you want to go the inside-out-object way or some other "late great OO framework".

IO::Handle actually abstracts little (it just gives some different syntax), and isn't the easiest to subclass. It doesn't really impress me.

[BrowserUk]

IO::Handle actually abstracts little (it just gives some different syntax),

It is a base class, it doesn't need to do more. And if it doesn't need to, it shouldn't.

If only more (usually self-described) OO-experts would learn that lesson.

For reference, compare IO::Handle with IO::Moose::Handle.

Contrast them for:

• Simplicity
• Understandability.
• Maintainability.
• Souce code weight.
• Load time weight.
• Run time efficiency.

The former knocks the spots of the latter in every single category.

and isn't the easiest to subclass.

And yet, a whole hierarchy of modules -- IO::Seekable, IO::File, IO::Socket, IO::Socket::INET et al. -- are sub-classed on top of it.

A file handle is a glob. It therefore has an associated hash and an associated array and even an associated scalar (which could hold a reference to a hash or an array). So, sub-classing is a doddle. It's just a matter of knowing the syntax.

And if you don't like any of those mechanisms, then you could always use the Tie::Handle method as used by IO::Socket::DNS.

It doesn't really impress me.

Maybe simplicity and pragmatism isn't your thing?

[zakame]

This.

Just the other day I asked Graham about the whereabouts of his old MojoX::Renderer::YAML module (it was removed from the CPAN sometime ago) and he showed me its Github repo. That module may be out of date (he said it doesn't work on Mojo 1.0 anymore) but still, it is helpful to know it is still out there :)