So, you don't start by creating a monster hash called %movies_data. That would be thinking about the data. OO is about thinking about the thing.

So what you need is an object called movie.

That object will represent the movie. Think of the object as a movie.

Don't fret about the data yet.

Okay, so you need an object called movie.

So how do we do that? This is OO -- it's all about the thing. So let's back off a bit and think about what a movie is.

A bunch of these would be called movies. And that's a clue to the next step.

A cat is a type of object. A house is a type of object. A movie is a type of object. They are all objects; but they are all different. We could say that they are somewhat defined by their attributes. So we will need to declare what type of object movie will be.

In OO, we call that a Class.

So we'll create a Class called Movies, and in it, define what attributes movies have.

Okay. So we need a Class called Movies. The other folks on this thread will be far better suited to give technical details. I have no need for objects in my world, and use them only when I have to in order to use somebody else's Perl Module.

But, in general, you will define an object called Movies, and in that definition, you will indicate that movies have attributes such as:

• title
• start year
• end year
• media
• based on
• company

Once you've defined your Movies Class, you're almost ready for the second earth-shifting part of converting to OO.

And the final shift necessary to think in Object-Oriented terms: Methods.

When you defined your Moviesclass, you would also have put in subroutines to perform tasks. Simple ones like setTitle , setMedia, that sort of thing. And more. Again, I leave it to the OO-savvy folks to get you details. This is about the shift in consciousness. About how to think in an object-oriented manner.

But you'll invoke those methods with a syntax something like this:

     $movies->setMedia("tv");

You've no doubt seen this sort of thing in your use of modules. Hopefully, now you see why.

There's a ton of stuff to learn regarding inheritence, but I'd let that go at first and let the lessons come as they are needed.

Only one step left in our journey -- which we have already taken, but now will describe: Instances.

Okay. You've defined a Class called Movies.

The next step will probably be somewhat familiar to you, especially if you've used Perl Modules that are OO.

You're ready to start mucking about with your first movie object -- Firefly.

     my $movie = Movies->new(title=>"Firefly");

I may have the syntax wrong -- as I've already indicated, I don't do OO except when required, and then I beat the Synopsis examples with a cudgel until I get something out of it that seems to do what I want.

But you -- Brave OO soldier that you are -- now you have created a movieobject from the Moviesclass.

You can do stuff with it now.

You have a class called Movies.
You have an object called movie. (It's currently stored in your Perl scalar called $movie).

But this simple example belies the power of OO.

You can now create multiple instances of that object.

Firefly is a movie (as defined in your original hash, anyway). But so is Iron Man. And so on.

Each of these is an instance of the movieobject, from the Moviesclass.

You can create any number of movieobjects as you need in your code, for whatever purpose.

    my $oldFavorite = Movies->new(title=>"FireFly");
    my $newFavorite = Movies->new(title=>"Iron Man");

    $oldFavorite->setMedia("tv");
    $newFavorite->setMedia("film");

    $oldFavorite->demote();
    $newFavorite->promote();
[download]

This wasn't meant teach you to code OO; it was meant to demonstrate how OO changes the way you look at programming.

If it helps, great.
If not -- well, I tried.

Good luck!

One of the benefits of OO is being able to organize your thoughts and design your solution. OO tends to persuade the coder to not just bash out a bunch of code, but instead plan and refactor. What you did was post 7 nodes of stream-of-thought off the top of your head consciousness without bothering to write a rough draft and refactor your repeated thoughts. Very non-OO.

One of the benefits of OO is being able to organize your thoughts and design your solution. OO tends to persuade the coder to not just bash out a bunch of code, but instead plan and refactor. What you did was post 7 nodes of stream-of-thought off the top of your head consciousness without bothering to write a rough draft and refactor your repeated thoughts. Very non-OO.

And very much appreciated.

Compared to just blobs of code almost everybody always posts , watching somebody go through their thinking process is very much appreciated -- its practically priceless.

How the fuck can you complain about that?

You can't skip steps and arrive at a solution and understand why you got there and why its good

Agree about Java. Learning Java helps too. Very much. You don't even need to read all the book, cause a lot of it is about Java classes. Just read language concepts.

The main point is: perl allows you to do anything anyhow and it works. Java forces you to use OOP. Reading, some helloworld codings with change your POV to the coding at all.

And after that you see that perl is really awesome (except exceptions). You may make fast and dirty, or you may do correct way and let's say 'enterprise'. Depending on goals.