in reply to Re^3: RFC: OO Perl using Moo/Moose book
in thread RFC: OO Perl using Moo/Moose book

I'm familiar with it, yeah, but it's pretty different from the kind of thing I want to do.

I want to write something that teaches good OO design (when to use roles, when to use inheritance, when to use delegation, etc) and just happens to use Perl for its examples. His is more focused on the mechanics of OO in Perl. Like he has about 2˝ chapters on bless and the different types of references it can be applied to, whereas I only plan to mention bless in passing.

It is also about 20 years old, so doesn't even mention stuff like Moose.

I want to write a book that a Python, Ruby, or Java programmer can read and learn from, and take away valuable advice even if they don't learn any more Perl than is necessary to grok the examples. (Though hopefully the examples will be beautiful and elegant enough that they are tempted to learn a bit more about Perl.)

toby döt ink

Replies are listed 'Best First'.
Re^5: RFC: OO Perl using Moo/Moose book
by LanX (Saint) on Apr 26, 2019 at 17:04 UTC
    Yeah I just mentioned it because you said "from the ground up"

    Things like encapsulation and polymorphism are well explained.

    And a new user should be aware that classes are just packages.

    > when to use roles, when to use inheritance, when to use delegation, etc

    You could use the dynamic of the monastery to discuss these concepts little by little.

    > Python, Ruby, or Java 

    Well are there any good Python or Ruby books on the topic?

    I'd say orientation towards Java would cause too much conceptual problems.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]

      "Classes are just packages" pre-supposes a class-based paradigm. I want to put less emphasis on classes and more on objects. It's possible to create objects by composing roles on-the-fly, for example. And even though these objects are still backed by packages and stashes and stuff, you don't have to think of each class being a package and being defined in a module.

      This is stuff which is hard to do properly in languages like Java, but you can still use it to conceive how you design your program, and then "down translate" that into whatever programming language you're using. For example, something like roles/traits/mixins can be emulated in Java using a combination of interfaces and delegation.

      toby döt ink
[reply]
        > "Classes are just packages" pre-supposes a class-based paradigm.

        so your definition of "Delegation" goes into the direction of the traditional JS model where objects "beget"° other objects?

        While this is certainly very important, I'd rather prefer a general book listing usual patterns for dynamic languages.

        It's very hard to discuss OO when the terminology is dominated by GoF book concepts from the static typing world.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        °) beget borrowed from Crockford's "JS the good parts" book

[reply]

In Section Meditations