Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Perl 6, Object Orientation and Melting Brains

by willyyam (Priest)
on Mar 27, 2005 at 20:45 UTC ( #442699=perlquestion: print w/replies, xml ) Need Help??

willyyam has asked for the wisdom of the Perl Monks concerning the following question:

I was just reading this node: 442402, and noted that there are many changes in Perl 6 that give every appearance of making it more Object Oriented. All well and good, but I still program everything like it's a lathe (purely procedural) and I've been trying to get my head around OO for 15 years and made no progress. Every time I try to make sense of OO programming it just stops a the eyes and won't go in. That's the background, here are the questions:

How much of my (largely bad, wholly untutored) Perl 5 code will break when I upgrade to Perl 6?

How am I going to get better as a programmer if, just as I'm getting comfortable with them, my tools shift under my feet?

If I am going to be forced to become comfortable with OO programming because all of the easy-to-use tools move to an OO architecture, how do I learn OO without melting my brain?

Any insight would be appreciated, thanks.

  • Comment on Perl 6, Object Orientation and Melting Brains

Replies are listed 'Best First'.
Re: Perl 6, Object Orientation and Melting Brains
by CountZero (Bishop) on Mar 27, 2005 at 21:12 UTC
    As Larry Wall wrote in Apocalypse 1:
    I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class.
    And in Synopsis 1 it is stated:
    # Migration is important. The perl interpreter will assume that it is being fed Perl 5 code unless the code starts with a "class" or "module" keyword, or you specifically tell it you're running Perl 6 code in some other way, such as by:
    #!/usr/bin/perl6 use v6.0; v6;
    So it looks that you can switch to Perl6 and still use most (if not all) of your Perl5 code and coding habits and slowly make the transformation module by module when you get more confident in your Perl 6 skills.

    And as for OO:

    If you want to treat everything as objects in Perl 6, Perl will help you do that. If you don't want to treat everything as objects, Perl will help you with that viewpoint as well. (Synopsis 1)

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Perl 6, Object Orientation and Melting Brains
by BrentDax (Hermit) on Mar 28, 2005 at 01:34 UTC

    Essentially, all data in Perl 6 will be in the form of an object.

    That doesn't mean you're going to have to put dot operators everywhere, though. Perl 6 will support alternate syntaxes (lc $string and print $fh: "foo") for people who don't want to think about methods. A few features will require use of objects, but most of them are ones that are only interesting to people designing classes anyway. (A notable exception is the grammars feature, which is implemented in terms of classes. Basic regex use doesn't require OO, but combining them into formal grammars does.)

    Oh, and there will likely be a mechanism for a user to give a class a CGI.pm-style default object. I don't think the exact syntax has been worked out yet.

    Edit: I forgot to mention that "everything is an object" doesn't mean "everything is passed by reference". In Perl 6, $letters="abc"; $company=$letters; $company ~~ s/a/b/; won't change the "a" in $letters.

    =cut
    --Brent Dax
    There is no sig.

Re: Perl 6, Object Orientation and Melting Brains
by revdiablo (Prior) on Mar 28, 2005 at 05:00 UTC
    I've been trying to get my head around OO for 15 years and made no progress ... how do I learn OO without melting my brain?

    I am not sure whether you are talking about creating object oriented code, or using object oriented APIs. What you mean can have a lot of implications on the answer.

    If you mean the former, then no, you will not be forced to write all your code in an object oriented way. Even in languages that try to force this sort of thing on their users, you can usually write procedural code in an object-oriented wrapper. This does not require much more than learning some syntax, and proceeding to do things essentially the same way you always have.

    If you're talking about using APIs that are more object-oriented, then perhaps. Perl 6 will make most everything look like an object (even if it's not truly an object, it will at least look like it). As BrentDax mentioned, there will be ways to access the functionality with alternate syntaxes, but learning the OO way might be advantageous.

    Do not despair, though. If made reasonably -- which I think most Perl APIs tend to be -- learning how to use an object oriented interface is not very difficult. In fact, I find it difficult to believe you haven't already, after using Perl for very long. You just might not realize it.

      I wrote:

      I've been trying to get my head around OO for 15 years and made no progress ... how do I learn OO without melting my brain?

      And revdiablo responded:

      I am not sure whether you are talking about creating object oriented code, or using object oriented APIs. What you mean can have a lot of implications on the answer.

      A good question. I think that the answer is that I wish to be able to a) understand and b) create OO code. I have indeed used OO API's, but my experience with them has been like a scene from "A Fish Called Wanda":

      Otto: Apes don't read philosophy!
      Wanda: Yes, they do, they just don't understand it!

      Where I think I get lost is that I can learn syntax, but I don't see the point, the reason the syntax is designed to reflect a structure that is, thusfar, beyond my grasp.

        The differences between procedural programming and OO (or functional or logical) programming are all about who is responsible for what. In procedural programming, The Programmer is responsible for everything. It is He who determines when everything happens, what data structures are used, what algorithms, etc. If there is a bit-shifting or memory allocation, He has made it so.

        The other styles are about sharing this rather awesome responsibility. It's a lot easier to see in logical programming - makefiles, for example. When you program a makefile, you're saying "X transforms to Y in this fashion" a whole bunch of times. You then say "I need to get this to Z" and the program figures the rest out. It figures out where you are, where you want to go, and how to get there. All the programmer has done is to provide the rules for getting from X to Y. It's kinda like have a butler in charge of your servants.

        In OO, it's kinda the same thing, except that you don't have a butler - you are the butler. Each of the objects is a servant. "Hey you! Please get this done." Now, you really couldn't care less how the maid cleans the living room, just so long as the living room is clean when you get back. You don't care if one person did it or if that maid hired a cleaning service to come in and do it. All you care about is that you have a person who is responsible for cleaning the room. If the room isn't clean, you know who to get mad at. :-)

        Functional is a little weird - you have a butler that will create the servants it needs on-demand, based on a set of templates. It doesn't really work with this analogy. *grins*

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Imagine for a moment that you're writing the billing component of an online store. Now, there are several ways a customer can pay: they can use a credit card, a debit card, a check, etc. You could use a switch statement (or an if/elsif chain in Perl 5) to do it:

        given ($payment_method) { # All code samples are Perl 6 when 'credit' { do_credit_card($num, $exp) } when 'debit' { do_debit_card($num, $exp) } when 'check' { do_check() } default { die } }

        But maybe there are several steps involved--early in the process you have to authorize, then later you have to execute the transaction, and perhaps you need to store the info in a database so crackers can steal it. That requires three switch statements in different areas of the code. And then six months down the road, you want to add PayPal support, so you have to change three different switch statements, but in one of them you accidentally put 'payapl', but it's already gone into production so the company loses five thousand dollars and fires you.

        You don't want to get fired.

        So instead, you write an object to represent a payment method, and a subclass for each specific way of paying:

        class MyStore::PayMethod { # A submethod is a method that isn't inherited. submethod new { die "Create a subclass, silly." } method authorize($price) { ... } method execute($price) { ... } method store($dbh) { ... } } class MyStore::PayMethod::CreditCard is MyStore::PayMethod { # Colon means private--only code in this class can see # it. has ($:ccnum, $:ccexp, $:ccname); submethod BUILD($:ccname, $:ccnum, $:ccexp) {} method authorize($price) { (code to authorize) } method execute($price) { (code to execute) } method store($dbh) { (code to store) } }

        Now you can create the appropriate object exactly once:

        my $class; given($payment_method) { when 'credit' { $class=MyStore::PayMethod::CreditCard } when 'debit' { $class=MyStore::PayMethod::DebitCard } when 'check' { $class=MyStore::PayMethod::Check } } my $payobj=$class.new(*%params);

        And then later on, when it's time to authorize, all you need to do is put the statement $payobj.authorize()--no nasty switch required.

        In essence, an object is a way to make tasks with different data look the same to the outside world, even if the exact algorithm used to do that task to that data is radically different. It's a little like passing around a table of functions, only cleverer.

        Edit: a friendly elder reminded me that has requires parens when declaring multiple attributes, just like my and our in Perl 5.

        =cut
        --Brent Dax
        There is no sig.

        The main difference between object oriented programming and procedural programming can be boiled down to where the data is stored. If the data is stored by the main program, and passed in to the functions, that's usually procedural code. If the data is stored by the functions themselves, and the main code just asks the functions to do things, that is usually object oriented.

        As dragonchild said, this moves the responsibility of that data away from the person writing the main code, and onto the the person writing the object itself. Even if that person is the same person, the two different areas of code can be written in different frames of mind. I think it helps create clean separation of concerns. Also, it's often just darn convenient. Passing the same data structures around constantly can be a real pain. Objects are a solution to that problem.

Re: Perl 6, Object Orientation and Melting Brains
by ambs (Pilgrim) on Mar 27, 2005 at 20:55 UTC
    Of course I'm not the best person to talk about this. I read a little about Perl 6, looked a little to Parrot... nothing more.

    But, knowing Larry Wall (well, I don't know him) I can expect that Perl 6 supports procedural programming as well as Perl 5.

    Now, regarding other tools being available as OO modules will probably lead you to learn a little about OO.

    To learn OO I would suggest the O'Reilly book Learning Perl Objects, References & Modules by Randal L. Schwartz (check this page)

    Alberto Simões

Re: Perl 6, Object Orientation and Melting Brains
by perlfan (Curate) on Mar 29, 2005 at 04:07 UTC
    Fear not, willyyam. Not only will Perl 6 not force you to use any willy-nilly OO, "they" are making every possible effort to make the transition from Perl 5 to Perl 6 as painless (and unnecessary) as possible. The Ponie project is an effort to create a Perl 5 interpretor for Parrot, and there is a Perl 5 -> 6 converter in the works. The Perl 6 and Parrot folks realize that without providing a way to run all those wonderful Perl 5 scripts out there, there is a very small chance folks will even bother switching to Perl 6.
Re: Perl 6, Object Orientation and Melting Brains
by starbolin (Hermit) on Mar 31, 2005 at 06:42 UTC

    What do you mean I can't program PL-1 on my TRS-80?


    s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://442699]
Approved by Errto
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2019-12-07 20:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (162 votes). Check out past polls.

    Notices?