in reply to In praise of Perl's object system.

It's beautiful. It's simple. It's powerful. It's Perlish.

I can't agree that it's Perlish. Perl was never about minimalism, and the object system is as minimalistic as possible.

There are other indicators for the fact that the object system was bolted on afterwards: You have to know about the representation of objects (blessed references) to create one (compare with strings, where you just write "..." to create one), and the method call, a very common operation in OO code, uses a two-character syntax (compare to string concatenation, which is just one character).

Yes, it's simple. It's also powerful. But not perlish.

Also the fact that methods are just subs in a package is more of a burden than a blessing: it makes introspection of classical Perl 5 OO quite impossible, because you can never know if a sub is intended to be used as a method or a sub.

If you use a module which imports subroutines, they show up as methods in your class when you introspect by looking into the package. Worse, they hide methods of the same name which a superclass might have provided.

(Yes, there are ways to fix that - Moose and namespace::autoclean go long ways to help you with that - but it doesn't feel perlish to me that I have to install modules from CPAN to fix built-in behavior. It's just perlish that it's possible at all :-) ).

Perl 6 - links to (nearly) everything that is Perl 6.

Replies are listed 'Best First'.
Re^2: In praise of Perl's object system.
by eyepopslikeamosquito (Archbishop) on Sep 09, 2010 at 10:14 UTC

    There are other indicators for the fact that the object system was bolted on afterwards.
    Or as Larry likes to say, it wasn't "bolted on", it was "bolted through" :)
    It has often been claimed that Perl 5 OO was "bolted on", but that's inaccurate. It was "bolted through", at right angles to all other reference types, such that any reference could be blessed into being an object.
    The above Larry quote is taken from the "Some of the Problems with Perl 5 OO" section of A12.

[reply]
Re^2: In praise of Perl's object system.
by shmem (Chancellor) on Sep 12, 2010 at 09:33 UTC
    but it doesn't feel perlish to me that I have to install modules from CPAN to fix built-in behavior.

    Now that is very perlish - using modules to fix built-in behavior. 

    use strict;
use warnings;

    [download]
    although those are pragmas, and core. But see also perl5i
[reply]
[d/l]
      although those are pragmas, and core

      which makes all the difference when talking about installing, no?

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
Re^2: In praise of Perl's object system.
by phaylon (Curate) on Sep 20, 2010 at 17:24 UTC

    I can't say I agree. Perl 5's object orientation is high enough that you don't have to drop out of Perl 5 to extend it (for most things), and low enough that it doesn't trap you in any specific way of doing things. That's very perlish to me.

    If it weren't this powerful, we wouldn't have Moose today, but whatever people thought OO should be like when Perl 5 first got it.

    Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]

      This is exactly what I was thinking: A) the OO system in Perl5 is very Perlish to me and B) the low-level, flexible, "incompleteness" of it is the only reason we had a chance to arrive at a kit as cool and modern as Moose.

[reply]

        Right. And if one checks out MooseX::* on CPAN, it becomes evident that Moose itself is still developing and advancing. And since Moose itself is a library, updating it independently from Perl is a big win as well. I don't need to upgrade Perl and my whole ecosystem just to use a newer or better MooseX extension. Not mentioning the fact that Moose is optional, and its overhead can be skipped by falling back to pure Perl OO or lighter OO libraries when required. It all makes my job easier :)

        Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]
Re^2: In praise of Perl's object system.
by xiaoyafeng (Deacon) on Sep 17, 2010 at 04:13 UTC

    Well, IMHO perl6 OO system is absolute much better than perl5. Nevertheless, what I worry about is perl6 is becoming a language but not a powerful tool language like perl5 does.

    What does powerful tool mean? people who use it can spend seconds to resolve the problem. He doesn't care about model, inherit and such. I hope perl6 doesn't need to sacrifice sys admin to becoming a true OO language.



    I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

[reply]
      Just to be clear, I was talking about the Perl 5 object system, just as DStaal did.

      Now regarding your concerns, is there any reason to believe we are sacrificing usability for the average sysadmin?

      And would you care to explain the difference between a "language" and a "tool language"? I see a programming language as a tool to build programs with, so that distinction doesn't seem to make sense to me.

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]

        A little OT, sorry for any inconvenience.

        And would you care to explain the difference between a "language" and a "tool language"? I see a programming language as a tool to build programs with,

        What is a tool language? I think it should be meet below three demands(suggestions are welcome ;)):

        • get things done quickly.
        • easy/not strict grammar.
        • powerful ability to control system.
        Tool language is for system admin, DBA, or such else. Because they are a special part in IT circle. they maintain a system or a program which they don't know deeply. They are not programmer; They won't be interested in inherit, delegation or something else; all they concern are whether is a easy-used hammer to mend the system fast. That is why they like perl5,awk but not java, C++. Okay, as I mentioned before, perl6 OO is great, but it, I mean OO, is meaningless to the script less than 300 lines.

        Again, I don't say perl6 is not good, I just say perl6 is too like a regular language or say language for teaching. I hope to see perl6 can provide a way to those people are not received formal programming training.



        I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

[reply]
Re^2: In praise of Perl's object system.
by BrowserUk (Patriarch) on Oct 01, 2010 at 08:31 UTC
    Also the fact that methods are just subs in a package is more of a burden than a blessing: it makes introspection of classical Perl 5 OO quite impossible, because you can never know if a sub is intended to be used as a method or a sub.

    That's what documentation is for.

    Can you suggest one realistic scenario where there is a need to decide between a subroutine and a method at runtime?

    Please note. This is a genuine question. I can't think of one, but that doesn't mean that there isn't one.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      That's what documentation is for.

      Assuming a perfect world, in which you know which files to search in for documentation, I'd agree.

      Having worked with XML::LibXML I found the documentation to be scattered over so many different files (due to a steep inheritance hierarchy) that consulting the documentation was often more work than writing a small example, and using introspection.

      Can you suggest one realistic scenario where there is a need to decide between a subroutine and a method at runtime?

      Suppose you write some RPC interface, and the incoming data structure tells you what method to call on a certain object. In order to give the appropriate error message when it's not possible to call the method, you need to check if the method exists prior to calling it.

      You can't generally just try it, and catch a MethodDoesNotExist exception if it goes wrong, because that might be an internal error from within the called method too. And it's nice for the user to distinguish the "method does not exist" and "internal error while calling method" errors.

      But the real downside of the non-distinction between subs and methods is the fact that importing utility subs from modules makes them available as methods, and even if you don't care, somebody inheriting from your class wonders what's up with those weird method calls.

      This is a real problem, and has happened to the DBIx::Class users and developers. Their "solution" was namespace::autoclean, but it's really just a workaround, not a solution.

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
        Suppose you write some RPC interface, and the incoming data structure tells you what method to call on a certain object. In order to give the appropriate error message when it's not possible to call the method, you need to check if the method exists prior to calling it.

        You can't generally just try it, and catch a MethodDoesNotExist exception if it goes wrong, because that might be an internal error from within the called method too. And it's nice for the user to distinguish the "method does not exist" and "internal error while calling method" errors.

        Hm. In my opinion that is wrong.

        If I were using a module via RPC, I would want it to act exactly the same as if I were using it locally. If using it locally would raise an exception, I would want the same exception raised when calling it remotely with the same arguments. If it returns error codes, then that's what I want to receive. In this way, not only can I test locally; the local/remote state can be transparent to the calling code.

        The last thing I want to have to do, is start checking whether the interface layer has decided to "helpfully" turn the actual result of the remote call into some diagnostic, and then have look up what that diagnostic means in another set of documentation. Especially as the diagnostic would inevitably be couched in generic terms rather specific to the actual module being called. And then code special cases to deal with the same problem dependant upon whether it is local or remote.

        But the real downside of the non-distinction between subs and methods is the fact that importing utility subs from modules makes them available as methods, and even if you don't care, somebody inheriting from your class wonders what's up with those weird method calls.

        That's an education thing. Don't export subroutines from an OO package.

        If you have to have a module that both does OO, and exports subs, put the subs in a sub package name-space and export them from there.

        But better still, don't export "utility subs". Write them as class methods, and have them expect (and check for) the class parameter.

        I've still yet to see a use for introspection--beyond a simple ref--that isn't just an "in vogue", but bad, solution to problems, that should be addressed by better coding practices.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations