Re: Re: Objects in PERL

[Vuud]

Okay, so then my PERSON class would just create and maintain an object for each role a person could play. At that point they are not that complicated, so I dont think creating an OCCUPATION class to subclass off of would be necesary.

I thought the multiple would be good to do. I guess I will try it the other way

Thanks for the help! "I'm never going to work another day in my life. The Gods told me to relax... I'm gonna be hooked up right"

[Masem]

First off, now that I've slept on it, I think ROLE is a better name for a class than OCCUPATION. But I'll stick with the latter for now.

The only reason I'd define some OCCUPATION class is that while perl is not strongly typed, this allows you to check to make sure that a 'addOccupation' works right, and that you have some expected functions in which you can use in a call such as 'queryOccupations' in the PERSON class. The base class can be as simple as simply having a name of the occupation and a method to get it.

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

[mugwumpjism]

At that point they are not that complicated, so I dont think creating an OCCUPATION class to subclass off of would be necesary.

This is called using a Servant class, ie having one classes' attributes and members thrown into the master class, even though they should be in a seperate object. Generally it's best to avoid this, all you save is a little bit of performance at the expense of breaking your encapsulation.