use Perl

• Looks interesting, but... (Score:2)

  by samtregar (2699)

  Interesting stuff. Wouldn't it be easier to just override isa() though? For example, if I want to tell the world that I implement 'Viewable', then I could do:

    sub isa {
       my ($self, $pkg) = @_;
       return 1 if $pkg eq 'Viewable';
       return 1 if grep { $_->isa($pkg) } @ISA;
       return 0;
    }

  On the other hand, by writing a new module you could implement some useful stuff that Perl's OO left out, like compile-time checking of in
  • Re:Looks interesting, but... (Score:1)

    by chromatic (983)

    Yes, you could override isa(), or much about with the appropriate @ISA. However, per the example in the docs, an Airport is not an Arcade. The Airport has an Arcade. Surprisingly, the semantic distinction is important to me.
    • Re:Looks interesting, but... (Score:2)

      by samtregar (2699)

      Isn't the choice of inheritence or composition an implementation detail that should be private to the class? What kind of use case do you have where a caller needs to know whether an interface is implemented using inheritence or composition?

      -sam
      • Re:Looks interesting, but... (Score:1)

        by chromatic (983)

        That's exactly the point! Good thinking. :)

        Using isa() dictates that the implementation is inheritance (or, at least, that you have to fake up that you're inheriting).

        In Class::Interface, derived classes are automatically marked as implementing their parent class interfaces. Whether you inherit or not, by talking about interfaces instead you're saying "objects of this class can (or should) handle the messages an object of this type can". You just have to be a little more explicit if you're not s
• Have you seen ex::interface? (Score:1)

  by pdcawley (485)

  Which was my attempt at adding interface support some time back. And which I've since abandoned as I've become convinced that I like optimistic typing a lot thank you very much and that, even though Perl 6 will give you the ability to specify an argument's type, in general you shouldn't bother unless there's evidence that doing so will help things go a lot faster.
  • Re:Have you seen ex::interface? (Score:1)

    by chromatic (983)

    I didn't catch it on my first foray through the CPAN. Now that I've seen it, I see it does something I wanted to avoid.

    One of my goals is to support mixins without giving up the possibility of having interface checking. One can imagine a module that provides mixins that, grouped together, form a named interface. Mixing them into a class is simple:

    package RobotDog; use Animals mixin => ':Dog';

    RobotDog would now be marked as implementing the Dog interface, and it has the doglike methods from A
• Compile time checking (Score:1)

  by malte (1708)

  Hi, did you think about an (optional) compile time check of interface implementation using a CHECK block? The module is nice, however, I'd rather have something with the expressiveness of Class::Contract for interfaces, that lets you defined pre-, postconditions and invariants for methods; and a pony.
• Might slip in... (Score:1)

  by Elian (119)

  I'm seriously considering adding support for this into the Parrot core, though I don't know that anything will actually use it. It seems to me that most OO inheritance things aren't really is or has relationships (though they are both useful) but does relationships--presentations of guaranteed interfaces/protocols/method sets. I mean, who really cares if you're a sub-class of hash, or array, or frob, as long as you present the base hash or array or frob methods?
  
  • Re:Might slip in... (Score:1)

    by chromatic (983)

    The nice part about does is that if you get it right, you get is for (almost) free! (That's assuming Class::Interface does it correctly, anyway.)
    • Re:Might slip in... (Score:1)

      by Elian (119)

      True, but core support certainly doesn't hurt. :) Besides, having one low-level way to do it makes it more likely that languages layering on top of Parrot are going to use the common infrastructure, and that makes interoperability much nicer.