Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: perl OO - to use or not to use

by adrianh (Chancellor)
on Sep 14, 2003 at 13:14 UTC ( [id://291385]=note: print w/replies, xml ) Need Help??


in reply to perl OO - to use or not to use

Are there instances where OO perl is the only choice?

Not really. You can always write a piece of procedural code that will do the same thing as a piece of OO code.

However, there are many times when OO is a sensible choice. For example if you've got an existing OO system that needs extending, or an OO framework that matches your application.

Personally I find an OO approach makes most non-trivial applications simpler to develop - but this edges onto religious argument territory.

You may find Damian Conway's ten rules for when to use OO of interest.

Say you've written a pretty large program written mostly in proceduaral perl. Can you easily re-write that program in OO perl later if you choose to?

Depends. Often not. Procedural code often tends to separate data and the processes applied to that data. OO tends to do the opposite.

It is possible of course, but may be non-trivial.

Does anybody have any idea how perl 6's implementation of OO perl is going to be like? If so, is it going to be differnt from the current implementation?

Yes it will be different. We won't know the details until the next Apocalypse comes out. Reading the other Apocalypses gives some hints. At the very least we will see:

  • Classes as first class objects
  • Multi-methods
  • Decent encapsulation of attributes and code

Probably a lot more.

As I understand it the old Perl 5 style object system will still be usable, but the newer structures offer considerably more flexibility.

Replies are listed 'Best First'.
Re: Re: perl OO - to use or not to use
by IlyaM (Parson) on Sep 14, 2003 at 16:08 UTC
    Procedural code often tends to separate data and the processes applied to that data. OO tends to do the opposite.

    Often procedural code is written in pseudo-OO style. I.e when you see a lot of subs with signatures like

    sub do1($datastructure1, ..) sub do2($datastructure1, ..) sub do3($datastructure1, ..) sub do4($datastructure2, ..) sub do5($datastructure2, ..) sub do6($datastructure2, ..)
    It is relatively easily to convert to OO code. You put all subs which work on same data structures in same classes and then you apply various refactorings(like this, this and this) to get more ideomatic OO code.

    --
    Ilya Martynov, ilya@iponweb.net
    CTO IPonWEB (UK) Ltd
    Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
    Personal website - http://martynov.org

      Wouldn't the example you mentioned be considered OO programming anyways? I mean, it does the exact same thing as 'traditional' OO programming, it just has a slightly different form. Do we have to have a 'class' and then create an 'object' and then call a method on the object by using specialized syntax? Why would this: $obj->meth(); be considered OO and this meth($obj) not be?
        With OO, the subroutine "meth" could be inherited (exist in another namespace from which the object inherits). When called as a subroutine, the subroutine must exist in the current namespace (or some pretty heavy AUTOLOAD magic should be involved).

        Liz

        First of all I'd like to mention that the syntax is secondary to the design of system. It is possible to express OO design using purely procedural syntax (case in point: first C++ compilers were actually just preprocessors which generated C code they feed to real C compilers). And of course it is quite possible to write purely procedural code using OO syntax.

        The syntax meth($obj) will work as substitution for $obj->meth() until you need data abstraction (i.e. you don't have classes which share same interfaces, particulary your class tree is flat and you don't use inheritance). Some would argue that data abstraction is essential property of OO design and if a system doesn't use data abstraction it is not OO at all.

        --
        Ilya Martynov, ilya@iponweb.net
        CTO IPonWEB (UK) Ltd
        Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
        Personal website - http://martynov.org

        Do we have to have a 'class' and then create an 'object' and then call a method on the object by using specialized syntax?

        Yes, that is exactly the point of object oriented programming. For it to be OO programming, you need to be able to create multiple instances of a class with all attributes and functions implied by that class.

        Your second examples are not analagous. In the case of $obj->meth();, the programmer is calling a method which belongs to the class, or the instance of that class. In the case of meth($obj), the programmer is passing a variable to a function which has no inherent relationship to the variable passed. The examples may look somewhat similar, but they are doing very different things.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://291385]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (5)
As of 2024-03-29 15:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found