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.
  • I like to think of allomorphism as describing objects or classes that have the same semantics for a set of behaviors but may be unrelated structurally.

    • Is that any different from the idea of "interface" (as in Java), or is it just a different name for the same thing?
      • Interfaces in Java are horribly broken, but if you ignore the abominable implementation entirely and reconstruct the problem the Java designers almost tried to solve, you can get close to the idea.

        • Could you explain how Java interfaces are broken and how Roles save the day?
          • Java interfaces and types have separate namespaces. Thus if you have a closed library from which you cannot inherit or which you cannot modify, you cannot mark a new type as allomorphic (polymorphically equivalent). It's not really generic programming if you have to modify existing code to make it more generic.

            Java interfaces also don't provide any default implementation. Whereas roles don't dictate any particular mechanism by which the types achieve their allomorphism, Java interfaces are effectively

    • Sounds like Mac::Glue ... $bbedit->open vs $finder->open, etc.?
  • I'm not sure what traits solve (in this case) that mixins would not have solved, unless leaving the class hierarchy unaltered was critical to you. Anyway, I gotta admit, Class::Trait is pretty cool.
    • Well, since you specifically say "in this case", I suspect you already know the differences between traits and mixins. I just never considered using mixins since they're fundamentally broken and don't provide everything that traits do. Even if they weren't broken, I would probably still go with traits for the extra features. Starting with mixins only to switch to traits when I need the goodies means maintenance work down the road.

      • i'm unclear on the difference between mixins and traits, could someone explain it to me? i skimmed this paper (Traits: Composable Units of Behavior http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf [unibe.ch] ) and my conclusion was that the difference is that traits differ from mixins in two ways: (1) traits don't allow one to add new state (fields) to a class, (2) in the case of a name collision when you add multiple traits to a class, none of the colliding methods are imported (you must explicitly alias them);