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 reason, I fail to understand how mixins handle the problem more elegantly than Perl5 inheretance. Reading Apocalypse 12 does nothing to clear that up for me. I'll likely have to wait for Conway to write a Perl6 OO book before I'll understand all the new stuff.

        Regardless, thanks for the ponder fodder.

        • 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'