Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: Improving your skills by reading module sources

by JavaFan (Canon)
on Aug 03, 2011 at 13:33 UTC ( #918251=note: print w/ replies, xml ) Need Help??


in reply to Re: Improving your skills by reading module sources
in thread Improving your skills by reading module sources

You do know that the unit "Barr" is named after Graham, don't you? Which is the unit of measurement of misusing Perls OO system. Most programmers code will be expressed in milliBarrs, with Graham the only known coder to achieve 1 Barr.


Comment on Re^2: Improving your skills by reading module sources
Re^3: Improving your skills by reading module sources
by BrowserUk (Pope) on Aug 03, 2011 at 14:41 UTC
    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.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      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.

        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?


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

      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 :)

Re^3: Improving your skills by reading module sources
by armstd (Friar) on Aug 04, 2011 at 06:14 UTC

    ++ for making me laugh.

    --Dave

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://918251]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (13)
As of 2014-07-25 18:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (174 votes), past polls