in reply to Re: Overhead vs. ease of use in OOP
in thread Overhead vs. ease of use in OOP

Don't bother trying to force Perls OO into a Java style framework. Its not a good idea. You lose the flexibility of Perls OO model for what gain?
Don't you see the contradiction in this? The complaint that Perl's OO is so bare bones that you have to do everything yourself is often parried with "but that makes it so flexible". After that, everyone turns around and implements objects using hashrefs, throwing decades of programming sense (scopes, namespaces) out of the window. And if someone tries to program OO in a different way, he/she is frowned upon Restricting yourself isn't always a bad idea - if it was, noone would use strict.

What's the benefit of flexibility if you're not supposed to be flexible?

Abigail

Replies are listed 'Best First'.
Re: Re: Overhead vs. ease of use in OOP
by demerphq (Chancellor) on Oct 19, 2003 at 23:14 UTC

    Just because something is possible doesnt mean its a good idea Abigail-II. Yes Perls OO is flexible. Yes its a good thing that can do Java style OO, but I don't particularly thinks its the best use of the flexibility perl provides. Theres a zillion other perlish OO variants that are more interesting, and actually solve real problems, not just a peevish dislike of using hash key/values or array slots, or glob slots or... as your object base.

    Frankly for me you are conflating two issues here. One is perls OO, the other is whether its a good idea to use dialects of Perl as provided by techniques like the one here, or source filters or the like. Generally I consider such dialects to be a bad idea. They make your code less maintainable, its not sufficient to have a good understanding of Perl, instead you need to have additional skills to work on the code base.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi