exists($args{Server}) ? $self->serverid($args{Server}) : $self->{SERVE
+R} = "0.0.0.0";
[download]

$self->serverid($args{Server} || "0.0.0.0");
[download]

Otherwise, where are you stuck?

thank you for the suggestion ^_^...i am stuck because i am not quite sure if what i am doing is right..
1.)is it ok if i use a lot of modules to create another module?is that advisable?
2.)would it be better if i use pack/unpack(i still need to learn it though) to decode the packet rather than using the modules?
3.)how do i use the full potential of OOP?
=)

1) It's perfectly fine to build upon the work of others. OOP was developed with the idea of making it easy to reuse software.

2) Becoming comfortable with pack and unpack is always a good idea, but using a CPAN module is fine too, if it solves your problem.

3) Mastering the full potential of OOP could take a lifetime. In fact, I doubt anyone knows what its full potential really is. I would suggest incrementally improving your OOP skills whenever you can. Look at other people's code, and see how they solve problems using OOP. OOP techniques are especially helpful in managing the complexities that occur in large programs. Also look at modules that get used a lot like the standard modules which come with perl. Their interfaces have been carefully crafted to make them useful in a general purpose setting. As you see more examples of well-written OOP code, you should get a feel for when certain methods are better than others. The OOP system in perl is very flexible, so it's difficult to lay down hard and fast rules about when to do things one way or another.

My main question, though, is: does your code work the way you want it to?

I find you code virtually unreadable partly because of the semi-random positioning of the braces (in a style I personally dislike) but mostly because of the definitively random indentation..

Dual function getters/setters have supporters and detractors. I tend to write single function ones like this:

sub get_serverid  { $_[0]->{SERVER} }
sub set_serverid  { $_[0]->{SERVER} = $_[1] }

sub get_requestip { $_[0]->{REQIP} }
sub set_requestip { $_[0]->{REQIP} = $_[1] }

etc
[download]

Short and sweet. Note that you don't need return. Perl returns the last value evaluated in a sub automagically. Anyone who knows perl will know what these functions do. Even if you don't read perl they are documenting what they are supposed to do by their very name. While they are marginally less readable on the raw function side they are totally self documenting on the usage side. You can also add error checking to ensure logical arguments are passed to setters.

You can make them longer by doing (and this is standard perl indentation brace positioning BTW):

sub set_widget {
    my ($self, $arg) = @_;
    die "Can't set_widget to "$arg"\n" unless $arg =~ m/something/;
    $self->{WIDGET} = $arg;
}
[download]

Anyway if you are going to take the time to encapsulate then directly accessing objects like my $state = $self->{STATE}; at the start of create_packet() is a definite no no. my $state = $self->get_state; says it all. You are breaking encapsulation all over the place even though you have get/set methods. $self->{MACADDRESS} (you forgot to code a get/set for that) and $self->{INTERFACE} appear all over the place. They should be $self->get_mac $self->get_interface.....

i was not quite aware of the indentation.i was just writing the code and was trying to do it the way i can read it..(since it is not done yet, but it works though)..
i'll just have to change the the indentation later..thanks for your opinion ..i'll try applying your suggestions to the code..

btw, on the sub new i set
$self->{INTERFACE},$self->{MACADDRESS} etc. to get default
values if there are no arguments being passed ...that is why
i used $self->{MACADDRESS} $self->{INTERFACE} etc (incase the user does not pass any argument)..maybe i'm wrong..kindly check the sub new again please...

Indentation is not something to fix later. The whole idea is to make code more readable so you don't confuse yourself when you write it and people reading it don't get confused. I suggest you run it through perltidy. The fact that it works has nothing to do with indentation. See obfuscation for unreadable code that works just fine.

With OO you write accessors and then use them EXCLUSIVELY. The accessors provide the INTERFACE. By doing this you are free to change whatever you want about your internal object representation - so long as the accessors work the same all will be well with any code using your code.

Debug this:

my $interface = $obj->interrface;
$obj->{INTERRFACE} = $new_interface;
[download]

set_serverid{

my $self=shift;
  if(@_)
     {$self->{SERVER} = shift}
 }

getserverid{

$self->{SERVER};
}

$serverid=getserverid();
[download]

You could but it should look like this with "standard/common" perl indentation and some error checking. Also if you are going to set_xxx you should get_xxx, not getxxx or getXxx to be conSistent:

set_serverid {
    my $self = shift;
    if (@_) {
        $self->{SERVER} = shift;
    }
    else {
        die "No argument passed to set_serverid!\n";
    }
}

get_serverid {
    my $self = shift;
    $self->{SERVER};
}
[download]

shift syntax works fine for $self but often you might like to do a bit more error checking in your setters:

set_serverid {
    my ($self,$id) = @_;
    if (defined $id) {
        die "Invalid value for id '$id' in set_serverid!\n"
            unless $id > 0 and $id < 255;
        $self->{SERVER} = $id;
    }
    else {
        die "No argument passed to set_serverid!\n";
    }
}
[download]

As noted I like to start off with very simple accessors like:

sub get_serverid  { $_[0]->{SERVER} }
sub set_serverid  { $_[0]->{SERVER} = $_[1] }

sub get_requestip { $_[0]->{REQIP} }
sub set_requestip { $_[0]->{REQIP} = $_[1] }
[download]

The thing I like about this is that you can see typos in the hash key names very easily. Unless you are doing formal error checking on the set side you don't really need more.

Thank you very much...i learned a great deal from you...
i will post the revised code later after i finish my other task...
and hope you will check it out...
just to make sure if everything is in the right place... ;) thanks....