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.
  • the first time I heard about this concept was in 1996, studying the Java interface keyword. And the next step is "programming oriented to the interface", thinking in classes is bad. You must design witn roles in mind.
    • Interfaces are a special case of Roles actually. They are effectively pure abstract Roles. Roles however can provide a default implementation of a contracted (this is also called Design By Contract) method. This is why the override warning was removed from Moose (it did have this behavior for a very short period of time). The warning was penalizing a valid idiom.

  • Hi Ovid,

    Your example doesn't sound right to me. The job of a server is to serve requests; the job of an ORM is to give access to some persistence methods; merging both responsibilities into a single class, be it through inheritance or through roles, is confusing. I would rather have a ServerInfo class that keeps the persistent data, and a Server class that deals with requests, with a "has-a" relationship between them (and then it doesn't matter through which mechanism such classes are composed).

    Besides, I a

  • Role composition doesn't solve the method-explosion problem. Suggesting it does actually hides the obvious solution to the problem because to properly implement your role you need to create an ORM delegate anyway. The proper solution to this in Moose terms is:

        package Server;
        use Moose -traits Persistent( storage => SomeORM );

        has ip_address => ( i
            sa => 'IPAddress',
            is => 'ro',
         

  • (in Moose syntax because I haven't boned up on this part of the Perl 6 syntax yet)


    has '_orm' => (
        isa => 'SomeORM',
        is => 'ro',
        lazy_build => 1,
        builder => '_connect_to_orm',
        handles => [qw(find)],
    );

  • In a perfect Perl 6 world you'd implement an ORM not as a inheritance or delegation, but by providing a different low-level representation, which manages storage to a db.

    The object doesn't have to be aware that it's stored, you just have to provide a constructor that allows injecting of a different representation.

    Sadly Rakudo doesn't implement representation polymorphism yet, SMOP might do it already

  • I started responding in comments yesterday, but moved it to a blog post when it grew long. Then it grew longer ;-)

    Short story: I think moritz has hit the nail on the head, but I go into details about the ideas that dami, perigrin and hobbs commented about.

    http://blog.woobling.org/2009/10/roles-and-delegates-and-refactoring.html [woobling.org]