in reply to Overhead vs. ease of use in OOP

I think that this is a bad plan. You're adding another layer of potentially buggy code on top of what is already an inefficient mechanism (OO is slow).

I dont know how this could possibly make things easier. I would say that if you prefer Java style OO then program Java. 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? The freedom to type $attribute instead of $self->{attribute}? Id say thats not freedom thats handcuffs. I use all kinds of underlying reference types for my OO. I have blessed scalars, blessed regexes, blessed code refs, blessed arrays, blessed globs, and of course the ubiqutous blessed hashes, not to mention a little bit of Inside Out Objects. If you choose to write Java in perl then you lose out on all this froody grooveyness.

I will add one thing however ++ to you for effort and originality. You probably learned heaps from doing this, but I would say that this is nothing more than a cool learning project that highlights Perls underlying flexibility and power. But having such flexibility doesnt mean you should exploit it just to remain comfortable. Better to learn Perls OO inside out and then decide if you really have gained anything with this approach. I bet youll come to the same conclusion I have.

As an added point, let me give you an analgy: You want to swim but you dont have much experience with it. But you have lots of experience walking. Does it make sense to wear lead shoes just so you can walk under water? No not at all. When you are in the water then swim when you are on land walk. Don't try to make swimming just like walking, the whole point of swimming is that its different from walking.


---
demerphq

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

Replies are listed 'Best First'.
Re: Overhead vs. ease of use in OOP
by Abigail-II (Bishop) on Oct 19, 2003 at 13:12 UTC
    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

[reply]

      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

[reply]
[d/l]

In Section Meditations