Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: The world is not object oriented

by tilly (Archbishop)
on Jan 03, 2004 at 02:44 UTC ( #318448=note: print w/ replies, xml ) Need Help??


in reply to Re: The world is not object oriented
in thread The world is not object oriented

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.


Comment on Re: Re: The world is not object oriented
Re: Re: Re: The world is not object oriented
by hardburn (Abbot) on Jan 03, 2004 at 04:00 UTC

    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.

        I don't think that we are going to come to agreement on whether closures are objects.

        No, probably not.

        I don't think I really made this point very well above (which is my fault), but it's not that I put an absolute stamp on closures as objects. Rather, I think they can be used as a limited form of object, but they're not limited to OO, either.

        ----
        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-09-01 11:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (6 votes), past polls