Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: The world is not object oriented

by hardburn (Abbot)
on Jan 02, 2004 at 15:19 UTC ( [id://318330]=note: print w/replies, xml ) Need Help??


in reply to The world is not object oriented

The definition of OO is unclear

I've recently been reading Booch's "Object-Oriented Analysis and Design", which contained a passage that made the reason for all this confusion over what OO is suddenly clear for me: the term "object" arose independently from several branches of CS at about the same time, each expressing a similar idea, yet just different enough to be confusing.

In such a case, it seems foolish to define OO along a single means of implementation. In Java, classes are always defined with a class Foo, plus some optional inheirtance declaration, followed by a block containg the class definition. Objects are always defined with a Foo f = new Foo(); statement, plus some optional parameters to the constructor. If you're not doing that, you're not doing OO, as far as the Java people will tell you.

What they have really done is implemented a single kind of OO and ignored a large and useful number other kinds of OO. Perl's bless'd objects are roughly analogous to Java's object system, and it's the one that gets the most attention, but it's hardly the only one. Just off the top of my head, it also has:

  • Inside-out objects
  • Classless objects
  • Closures

And probably a lot more that I don't know about, or even have yet to be discovered. The important point is that these have massively different implementations, but can all be unified under the banner of OO.

Another thing I've noticed is some OO programmers describing OO concepts in terms of how it's implemented in their favorite language. It is ironic that OO, which is about abstracting the interface from the implementation, is often described in terms of implementation. For instance, I once saw a C++ programmer explain polymorphisim (here on Kuro5hin.org) like this:

Polymorphism - The class contains a pointer to the appropriate function to call that can handle the class specific data. This is done so to provide a consistant interface.

Yes, that's how polymorphism is implemented in C++. But it doesn't have to work like that. Perl's bless'd objects, for instance, does polymorphisim by walking the inheirtance tree (not that this is a great way to do it--it's slow).

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: The world is not object oriented
by Corion (Patriarch) on Jan 02, 2004 at 15:27 UTC
    Yes, that's how polymorphism is implemented in C++. But it doesn't have to work like that. Perl's bless'd objects, for instance, does polymorphisim by walking the inheirtance tree (not that this is a great way to do it--it's slow).

    No. The inheritance tree is called that, because it is used for implementing inheritance, not polymorphism. Polymorphism means you have several things, that you can treat in a uniform way, for example because they all implement the same interface. Polymorphism is (for example) usefull, when you are storing objects in a container, and the container somehow has to interact with its objects.

    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web

      The inheritance tree is called that, because it is used for implementing inheritance, not polymorphism. Polymorphism means you have several things, that you can treat in a uniform way, for example because they all implement the same interface.

      Subclasses, in general, have the same interface as their parents, which means that polymorphism and inheirtance are tightly bound.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        Yes and no. It's exceedingly difficult to have inheritance without polymorphism but it's exceedingly useful to have polymorphism without inheritance. Polymorphism is the principle. Inheritance is one application.

Re: Re: The world is not object oriented
by tilly (Archbishop) on Jan 03, 2004 at 02:44 UTC
    Correction. Closures are a distinctly different concept than objects. And making effective use of closures takes a different set of design skills than laying out a good OO design. (Neither is better than the other. They just don't translate very well.)

    A closure is distinctly simpler in behaviour than an object. They aren't a less capable building block since you can implement an object system with closures. But a single closure represents a far less rich set of behaviours than a single object, and closures offer fewer tools than objects do to channel and constrain your designs along natural paths. (Flexibility is definitely a somewhat mixed blessing.)

    Therefore it is incorrect to claim that closures are one of Perl's OO systems.

      I think they implement enough OO concepts to be considered objects in their own right. They're very simple, and only have one method, but they're still objects. They encapsulate behavior behind that method. They are also polymorphic, as long as they take the same parameters (curried versions can help there). I think it's fair to call them objects, and rather rigorious ones at that, though with limited functionality.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        I don't think that we are going to come to agreement on whether closures are objects. Of course you can shoehorn your understanding of closures into an OO framework. But that isn't a useful view because it seriously misleads you about how to actually make effective use of them.

        If I was going to put this as a linguistic metaphor, I'd say that objects make good nouns and closures make good verbs. You think about them completely differently, and you evolve designs with them differently as well. With objects you think about pieces that need to communicate with each other. With closures you evolve behaviours.

        But that is rather vague. Read Why I like functional programming, Re (tilly) 1 (perl): What Happened...(perils of porting from c) and Re (tilly) 1: 5x5 Puzzle to get an idea of how I use closures in practice. If you don't get a sense from that code that manipulating closures "feels different" than OO design, then I really don't have any idea how to communicate the mindset shift involved.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (4)
As of 2024-03-19 10:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found