Object oriented coding is not my cup of tea.
So ideally this section should be handled by someone else in the LUG crowd.
But since perl knowledge is not very high I will volunteer this time.
By the way you can attend my upcoming talk day after tomorrow. It is a
nice big hall that can accommodate a lot of people.
Please be there by 9am day after(18th Sunday). It is TalentSprint
right next to Gaudia Mutt in Royappetah opposite
Ponnusamy hotel and it is around 5 mins walk from Music academy.
Anyway now back to perl coding.
OO is not something with which you can bullshit and gain respect like
people tend to do with deep networking or crypto concepts.
It is a practical tool which is very useful for programming and of
course design.
The main purpose of OO is as they say information hiding or scaling.
Many programming languages including perl does not implement this
hiding business all that well. This is not to say that you can't do OO with C.
In fact Objective C used in apple products is supposed to be C with OO.
But even without that, just plain ANSI C can do OO albeit in a crude way.
We can use structures and pointers.
But why talk about C structures and pointers in a perl OO article?
Reason is simple.
In perl, OO Is implemented using hashes and references.
A Perl hash is roughly equivalent to a C structure.
A C structure can be opaque and can hold anything within it. More
structs, integers, strings, arrays and so on.
Of course in C there is no string data structure.
In higher level languages the only data structure people use by
default is a string.
Everything in higher level scripting languages is a string.
Anyway now a hash table or a hash or a dictionary or an associative
array or a structure is nothing but a bunch of
key value pairs.
A key can be just a name , in the case of C it is a variable name; in
perl it is an explicit name given to retrieve the value.
It could be a string or an integer.
The value is what counts. The value is what is stored in the hash and
that is our interest.
Obviiously in a perl hash we can store anything as a value.
Yesterday we saw how we could store an array reference as a value.
This is because every value in a hash table is a single entity.
It cannot be plural.
In other words in mathematical terms, it is a into mapping. One to one.
Anyway let us take a simple hash table.
%foo = ( name => "girish", sex => "male", exp => 20, designation =>
"engineer", runcode => $funcref);
Here is a simple record for the person girish.
The most interesting part is the runcode => $funcref.
Say,
sub func {
print " I am inside the func";
}
&func;
will call it.
Now I can get a refrence:
$funcref = \&func;
You can call the function by
&$funcref;
Since all references are singular values and since you can hide any
aggregate data inside it,
all references can be a hash table value.
Consider:
%foo = ( name => "test", coderef => $funcref, array =>
[2,3,4,"nothing"], hashref => { 1 => "hash", 2 => "bar", name =>
"hashref" });
Now you can see that a hash can be formed with anything inside it.
Now you can get a reference to this complex hash.
$r = \%foo;
Now you can claim that $r is an object with a strong, a function, an
array and a hash.
This is the most basic idea of an object.
You hide what is inside the object by a reference, since it is just
like a C pointer. It can hold any address.
And you can always retrieve each object member by using a key.
The other aspect of an object is the lack of order. No sequencing.
This is also true of hash tables. No ordering.
Today we have seen a lot of theory.
Tomorrow we will see some real OO examples.
-Girish
--
G3 Tech
Networking appliance company
web: http://g3tech.in ?mail: girish at g3tech.in
