use Perl

• Read more than just Perl books! (Score:2)

  by brian_d_foy (44)

  It's already been written. It just doesn't use Perl. Good design transcends language.
  
  But, this book wouldn't sell. It would be a great book, but no one would buy it (where no one means fewer people than it takes to keep the economic incentive above working at Starbucks instead).
  
  I don't see the word "Perl" in the title magically making this a sellable or interesting book. People interested in good design are the same people that read about design despite the language.
  
  I here rumor that the Perl book topics wi
• You don't want a book... (Score:1)

  by Alias (5735)

  ... you want to educate the masses.
  
  And unfortunately, for the most part (rare exceptions like Perl Best Practices excluded) books don't educate the masses.
  
  Things like perlcritic rules are far more likely to have the impact that you want.
  
  I think there's a number of interesting perlcritic rules that could be implemented based on your examples (most of which I agree with)
  
• Damian covers these concepts... (Score:2)

  by cbrandtbuffalo (4462)

  I recently had the good fortune to attend Damian's Intermediate OO class and he does an excellent job of covering the concepts and context for many of the issues you raise. We just need to send every perl coder to Damian's course! :)
• Liskov can bite me (Score:2)

  by djberg96 (2603)

  "Why the Liskov Substitution Principle is important."

  It's important for academics who are more concerned with being correct than useful.

  Override nothing! Delegate everything!

  Ok, maybe I'm a wee bit bitter after losing a debate about Pathnames, Strings and subclassing.
  • Re: (Score:2)

    by Ovid (2709)

    I think you must be thinking about something else. Liskov doesn't say anything about not being able to override anything. It merely states that a subclass must be substitutable for the parent class without affecting the correctness of a program. You can override all you want, just make sure that the interface doesn't change.
• I don't get it (Score:1)

  by hex (3272)

  # Hello Demeter!  (Yeah, this is contrived)
  my $office = $cust->salesman->manager->office;

  What's wrong with this?
  • Re: (Score:2)

    by Ovid (2709)

    my $office = $cust->salesman->manager->office;

    It's a question of encapsulation. Imagine that the Salesman class no longer has need of a manager accessor, but you still need to know which office the salesman is with. You might get a office method pushed into the Salesman class. Then, every place where you have the above code needs to be changed to:

    my $office = $cust->salesman->office;

    If that's called a lot, it can be a maintenance nightmare.

    However, what if you have this?

    sub Cus
    • Re: (Score:1)

      by hex (3272)

      You've properly encapsulated the hierarchical structure and greatly improved maintainability. Oh, I see what you mean now. Right, thanks.
      • Re: (Score:2)

        by Ovid (2709)

        You're welcome. It's not exactly intuitive. Took me a couple of tries to get it :)
    • Re: (Score:1)

      by perigrin (3495)

      Thank you. I hadn’t realized Moose’s powerful delegation mechanisms we’re more than handy shortcuts. This provides an excellent use case for them.

      For those who don’t know Moose every attribute object can have a handles er … attribute … so the example here can be defined like:

      package Salesman;
      use Moose;
      
      has manager  => (
          ...
          handles => [qw( office )],
      );
      
      package Cusotomer;
      use Moose;
      
      has salesman => (
          isa => 'Salesm
      • Re: (Score:1)

        by avik (3911)

        Thanks for very thoughtful approach to teaching OO. Unfortunately, in my college days we learned OO in a worsed possible way (questionable faculty, clueless students, books never used).