Re: Re: perl6 & OO

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

Comment on Re: Re: perl6 & OO Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: perl6 & OO by awwaiid (Friar) on Feb 19, 2004 at 20:49 UTC
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 :)	[reply]

Replies are listed 'Best First'.

Re: Re: Re: perl6 & OO
by awwaiid (Friar) on Feb 19, 2004 at 20:49 UTC

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

[reply]