use Perl

• Type Safety with Roles (Score:1)

  by chromatic (983)

  Because interfaces are not used, you don't have the problem with duplicate code, but you do get the benefit of knowing the methods are implemented (and that required methods are available.)

  Also, unlike Java's interfaces, role names and type names share a namespace. That's all of the goodness of allomorphic type checking in signatures.
  • Re:Type Safety with Roles (Score:2)

    by Ovid (2709)

    I thought I had posted a response, but apparently I had not :(

    First, can you give a clear definition of "allomorphism"? Try as I might, I can't quite understand it. It seems like allomorphism [c2.com] is similar to polymorphism, except you can override behavior on an instance level instead of a class level and all that's relevant is that the interface is consistent. Is that correct? I think not because it's too simple.

    Also, I'm not sure what you mean by "role names and type names share a namespace." What be
• Class layout (Score:1)

  by jhannah (5254)

  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

  --
  Omaha Perl Mongers [pm.org]
  • Re:Class layout (Score:2)

    by Ovid (2709)

    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
    • Re:Class layout (Score:1)

      by jhannah (5254)

      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

      --
      Omaha Perl Mongers [pm.org]
      • Re:Class layout (Score:2)

        by Ovid (2709)

        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'
• Decorator Pattern? (Score:1)

  by jhannah (5254)

  Also (now) wondering if the Decorator design pattern would do the trick. One of O'Reilly's sample chapters reminded me of this post...
  
  http://www.oreilly.com/catalog/hfdesignpat/chapter/index.html [oreilly.com]
  
  j

  --
  Omaha Perl Mongers [pm.org]