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

Re: perl6 & OO

by awwaiid (Friar)
on Feb 19, 2004 at 15:59 UTC ( [id://330233]=note: print w/replies, xml ) Need Help??


in reply to perl6 & OO

I've always thought that OO is better conceptualized as a fancy syntax for passing a datastructure as the first argument to a function. The really important part of OOP is not objects but rather modules... keeping code clean compartmentalized. In perl the syntax boost is on the object-users' end and not so much on the object-implementors' end... making the overall syntactical sugar slightly less sweet. I think it does go in line with the rest of Perl, however... considering the parameter passing technique for example.

So though I agree that the current way is nice and minimalist, I think that a bit more sugar wouldn't hurt :)

Replies are listed 'Best First'.
Re: Re: perl6 & OO
by hardburn (Abbot) on Feb 19, 2004 at 20:28 UTC

    No. Thinking about objects in terms of fancy data strucutres tends to lead to bad OO design. One of my personal rules is that bad OO is worse than no OO at all. Perl's bless object system doesn't help this state, because it comes right out and says "Hi, I'm a datastructure, and now I'm an object, too!", whereas most languages have the good sense to hide this dirty little secret.

    The trick to thinking in OO is to stop thinking about the underlieing data. You can know it's there, but you don't touch it yourself. Instead, you're calling methods that provide the means to munge the data in predefined ways.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      I think you bring up a very important point about OOP. Perhaps this is the difference between an imperative view and a functional view. Your view, which I'm taking to be the imperative view, might say that we do things with objects. We command them to keep track of a new setting or to tell us about themselves.

      In the functional view we would instead say that an object is more of an expert -- an expert at manipulating a specific data structure. We give it the old data structure and ask for a manipulation and it gives us back a new data structure. You could think of each and every method as a function which maps the old datastructure onto the new one. Often functional languages which have objects use this viewpoint, and for me Perl does too.

      But thats one of the reasons that perl is so cool... you can look at it either way :)

Re: Re: perl6 & OO
by flyingmoose (Priest) on Feb 19, 2004 at 18:26 UTC
    This fairly well summarizes my views of (the most important part of) OO. Essentially you want to manage instances and scope. Polymorphism, inheritance, and encapsulation are given as the 3 tenets, but the first is the concept of keeping instance data and functions clean and orderly. It's possible to write code in a non-OO way that reaps 80% of the gains. You can go a heck of a long way with C code that always takes pointers to structs as first arguments...it's just less sugary. Perl is somewhere between that C-style and languages that fully support require OO. I'd like it to move a little more right, but not all the way to the right.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (9)
As of 2024-04-24 08:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found