Re: Why is a hash the default "object" in oo perl?

in reply to Why is a hash the default "object" in oo perl?

Like blockhead, your post immediately made me think of inside-out objects. And I must say, the fact that you came up with the idea all on your own is quite impressive to me. It took me a while to even understand the technique when I read about it, much less did I think of it myself. Very clever! :)

Comment on Re: Why is a hash the default "object" in oo perl?

Replies are listed 'Best First'.
Re^2: Why is a hash the default "object" in oo perl? by theAcolyte (Pilgrim) on Jul 19, 2004 at 00:10 UTC
Heh ... thanks! Really what was bothering me was a statement I've read over and over in texts that deal with Object-Oriented programming (but not about using it in any particular language) which was: A subclass shouldn't need to know anything about its parent's implementation, and the parent shouldn't need to know anything about a child's implementation Or something along those lines. And while I was experimenting by trying to create a very generic "person" object (which could then become person::client, person::employee, person::vendor etc) I realized that I would end up violating both of those ideas by storing data inside a hash-ref as object If I had been working on this for a paid project I would have just plowed forward as I'd be the one writting the subclasses anyway ... However, since this was a learning experience, I was annoyed by the idea of 'cheating' and figured there had to be a way. I had once seen (here on perlmonks) using braces around a subroutine { $var; sub { ... }} to keep a variable alive between calls to the subroutine and used that in figuring out what I did. I think after I read/learn Abigails implementation -- which I have no doubts is much more refined then my Saturday afternoon of hacking around -- I would likely use this as my default OO style. theAcolyte	[reply]

Replies are listed 'Best First'.

Re^2: Why is a hash the default "object" in oo perl?
by theAcolyte (Pilgrim) on Jul 19, 2004 at 00:10 UTC

A subclass shouldn't need to know anything about its parent's implementation, and the parent shouldn't need to know anything about a child's implementation

Or something along those lines. And while I was experimenting by trying to create a very generic "person" object (which could then become person::client, person::employee, person::vendor etc) I realized that I would end up violating both of those ideas by storing data inside a hash-ref as object

If I had been working on this for a paid project I would have just plowed forward as I'd be the one writting the subclasses anyway ...

However, since this was a learning experience, I was annoyed by the idea of 'cheating' and figured there had to be a way. I had once seen (here on perlmonks) using braces around a subroutine { $var; sub { ... }} to keep a variable alive between calls to the subroutine and used that in figuring out what I did.

I think after I read/learn Abigails implementation -- which I have no doubts is much more refined then my Saturday afternoon of hacking around -- I would likely use this as my default OO style.

theAcolyte

[reply]

In Section Meditations