Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • At a glance, if I was going to design the class structure you were looking for, I'd start with something like this:

    - Character
      - Race
        - Elf (@ISA InfraVision)
          - Drow
        - Human
        - Dwarf
      - Class
        - Thief (sub pick_pocket)
        - Magician

      - ElvenThief (@ISA Elf, Thief)
      - DwarfThief (@ISA Drawf, Thief)

    - Skills (contains defaults skill level settings)
      - Vision
        - InfraVision
       - Thef

    • With all due respect, I think you've inadvertently illustrated my point. Let's stick with Perl 5 and assume that delegation is the key to performing profession-specific behavior, but we won't use delegation yet. We'll assume four races, human, elf, dwarf and halfling. We'll also assume four professions, fighter, thief, magician and cleric. With the Character and Profession abstract base classes, we have a grand total of ten classes, each which encapsulates the basic attributes of what they're trying to m

      • 1) I agree that a class structure for each class / race would get way out of hand. I fail to understand why you need a class structure to handle the problem in the first place. It seems to me that every character could attempt any behaviour, so you could just have a default set of skill levels, and perform procedural adjustment to those stats based on classes/races. I have no idea what methods / attributes would useful in individual class / race classes.

        2) If the class structure *is* needed for some reaso

        • Those are valid questions. The truth is, you never need objects to accomplish any programming problem. I chose objects for this illustration primarily because characters are really bundles of data with behaviors attached to them. This, of course, is one way objects are defined.

          As for how mixins solve the problem more elegantly, you might want to read a virtually identical node on Perlmonks [perlmonks.org]. In light of the responses, I back off a bit from asserting the utility of mixins once it became clear that they're implemented via anonymous inner classes; that brings inheritance back in the picture and one then needs a plethora of anonymous roles or classes to manage the ordering problems -- not good. I'm sure there is a simpler solution and, if so, I'd be happy to see it. However, the main point of this thread was about the utility of roles and mixins, not about how they solve D&D problems :)

          If you're comfortable with OO, I strongly recommend you read about traits [unibe.ch] (not Perl 6 traits.) Inheritance is great, but polymorphism is the true power of OO. You can think of traits as extending polymorphism without the problems with inheritance (naturally, that's an oversimplification.)