crazedrat:
You'll generally have better luck with your classes if you design your classes further in advance of when they are due.... 8^)
Anyway, a few notes to help you on your way:
I tend to use a package like Data::Dump for debugging,as it will print the information in an easy format, so I can verify that the data is or isn't what I expect to see. Instead of your main program, I used this:
use strict;
use warnings;
use Employee;
use EmployeeList;
use Data::Dump 'pp';
my $E1 = new Employee( {name=>'George', hours=>40, hourlywage=>50.00}
+);
print "What does Data::Dump see for my Employee?\n";
pp($E1);
print "\nHow does it print?\n";
$E1->print_student();
It looks like you were a bit optimistic. The Employee class looks like it constructs itself correctly, but the print_student method does no such thing:
$ perl classes.pl
What does Data::Dump see for my Employee?
bless({ hourlywage => 50, hours => 40, name => "George" }, "Employee")
How does it print?
Here, the problem appears to be a simple naming issue--a method named "print_student" implies that (a) it's actually going to print something, and (b) that it's going to print a student. There's nothing in your Employee class that lets us figure out whether it's actually a student or not, so I'm guessing it's a holdover from a previous assignment. I'd suggest renaming your method to indicate what it's actually going to do, which is to format the employee as a string. I'll just settle for calling it "format" for now and updating the code. After making the appropriate edits, I get:
$ perl classes.pl
What does Data::Dump see for my Employee?
bless({ hourlywage => 50, hours => 40, name => "George" }, "Employee")
How does it print?
Employee info: name: George hours: 40 wage: 50
OK, that went well. Next let's add a couple more Employees, make an EmployeeList, add the Employees to the list and see what we get:
use strict;
use warnings;
use Employee;
use EmployeeList;
use Data::Dump 'pp';
my $E1 = new Employee( {name=>'George', hours=>40, hourlywage=>50.00
+} );
print "What does Data::Dump see for my Employee?\n";
pp($E1);
print "\nHow does it print?\n";
print $E1->format();
print "\nLet's create a couple more employees and print them:\n";
my $E2 = new Employee( {name=>'Ellen', hours=>30, hourlywage=>35.00
+} );
my $E3 = new Employee( {name=>'Phideaux', hours=>10, hourlywage=> 5.00
+} );
print $E2->format(),
$E3->format();
print "\nNow we'll create an EmployeeList.",
"\nWhat does Data::Dump see when it's empty?\n";
my $L = new EmployeeList();
pp($L);
print "\nHow does an empty list print?\n";
print $L->format();
$L->set_EmployeeList( [ $E1, $E2, $E3 ] );
print "\nAfter adding George, Ellen and Phideaux, our list looks like:
+\n";
pp($L);
print "\nHow does it look using the built-in formatter?\n";
print $L->format();
print "\nDoes get_EmployeeList work?\n";
pp($L->get_EmployeeList());
OK, when we run it, we get:
$ perl classes.pl
What does Data::Dump see for my Employee?
bless({ hourlywage => 50, hours => 40, name => "George" }, "Employee")
How does it print?
Employee info: name: George hours: 40 wage: 50
Let's create a couple more employees and print them:
Employee info: name: Ellen hours: 30 wage: 35
Employee info: name: Phideaux hours: 10 wage: 5
Now we'll create an EmployeeList.
What does Data::Dump see when it's empty?
bless({ EmployeeList => [] }, "EmployeeList")
How does an empty list print?
Employee info: ARRAY(0x60028cbd8)
After adding George, Ellen and Phideaux, our list looks like:
bless({
EmployeeList => [
bless({ hourlywage => 50, hours => 40, name => "George" }, "Employ
+ee"),
bless({ hourlywage => 35, hours => 30, name => "Ellen" }, "Employe
+e"),
bless({ hourlywage => 5, hours => 10, name => "Phideaux" }, "Emplo
+yee"),
],
}, "EmployeeList")
How does it look using the built-in formatter?
Employee info: ARRAY(0x600240278)
Does get_EmployeeList work?
[
bless({ hourlywage => 50, hours => 40, name => "George" }, "Employee
+"),
bless({ hourlywage => 35, hours => 30, name => "Ellen" }, "Employee"
+),
bless({ hourlywage => 5, hours => 10, name => "Phideaux" }, "Employe
+e"),
]
Overall, it's not too bad. We can successfully create the list and add employees to it and fetch it back.
The big problem at the moment is that the EmployeeList format() function just stringifies the list, making an ugly ARRAY(0x########) string rather than showing us a list of Employees.
To handle this, in your EmployeeList format() function, you'll want to iterate over each Employee in the list and then format each individual item. To start you along, here's how you can iterate in your format function:
package EmployeeList;
. . .
sub format {
my $self = shift;
for my $anEmployee ( @{ $self->{EmployeeList} } ) {
# Do something with the employee, such as:
# print "current employee name is: ", $anEmployee->{name}, ".\n"
+;
}
}
Here are a few suggestions on improving the code:
- Be careful with your function names: make them do what they say they're going to do or rename them to indicate what they actually do. Writing code is harder when function names mislead you.
- I'd suggest having methods that can add or delete a single employee from the EmployeeList. Having to pull all the employees out of the list into an array, then adding or deleting an employee to that array and then setting the EmployeeList to that array sounds like a rather painful way to manage the employees.
- For your query function(s), you're going to have to figure out what sorts of queries you want to do, and how you'd accomplish them. I'd suggest having your query function(s) return a *new* EmployeeList with the selected Employees, so you can refine your queries.
You could make a single query function that takes a complicated set of arguments to figure out what to do, like:
# Get a list of employees between ages 30 and 50 who make more than $2
+5/hr
my $interesting = $L->query( [ "AGE", "BETWEEN", 30, 50 ],
[ "HOURLY", "ABOVE", 25 ],
);
or multiple query functions that take simpler arguments:
my $interesting = $L->filter_age( 30, 50 )
->filter_hourly( 25, 99999999999999 );
My final bit of advice: Rather than writing the entire program at once, build it up feature by feature. If you have two hundred lines of untested code and have an error, you don't really know where that error is. Finding it can be a problem. But if you have a working program that you understand, and then write 20 lines of code to add a new feature, and then have a problem, it's easier to home in on the location of the error. Don't be afraid to add print statements anywhere in your program to see what's happening--you can take them out later when you don't need them. Even better--try to learn the debugger. It can be *very* educational running your program in the debugger since you can stop the code anywhere you want, examine values to see if they hold what you expected or not. You can even change data values to see what would happen in other cases.
...roboticus
When your only tool is a hammer, all problems look like your thumb. | 