perl OOP

A

a

Hi
I dont understand when we declare a new in a package. It is always use
new($class, %args).
For method, ususally method($self, %args) to pass input parameter. So, we
dont use the $class and $self anyway, what is the purpose putting there?

I have read the tutorials already but still not understand.

Thanks
 
M

Marc Espie

Hi
I dont understand when we declare a new in a package. It is always use
new($class, %args).

A typical new will create an object at some point, like

my $self = bless {}, $class;
....
return $self;

In the presence of inheritance, you don't necessarily know what the class
value is, because you might inherit your constructor unchanged from a base
class.
For method, ususally method($self, %args) to pass input parameter. So, we
dont use the $class and $self anyway, what is the purpose putting there?

The object very often has state, and you use that state in your methods.
One methods might set $self->{p} = value; and another one will use
$self->{p}.
I have read the tutorials already but still not understand.

You have to stop thinking in procedural terms and reorganise what you're
doing in terms of `objects', or you will never understand.

Try to find actual code that's already using objects correctly, try to redo
what it does with your usual techniques, and notice the difference.

OOP is deceptively simple: indeed, it will look like `what's the point' at
first, until you start writing simpler and clearer code thanks to it.
 
X

Xiong Changnian

I dont understand when we declare a new in a package. It is always use
new($class, %args).
For method, ususally method($self, %args) to pass input parameter. So, we
dont use the $class and $self anyway, what is the purpose putting there?

Sorry, but I think we don't really understand what you're asking. If
you're having trouble expressing yourself, you might want to find
someone fluent in both English and your native language to translate for
you.

I'll take a stab at it. Please note that the following examples are
extremely verbose -- plain but not particularly efficient.

Most methods are object methods. They are expect params of the form:

package Bottle;

sub name_me {
my $self = shift;
my $name = shift;

$self->{NAME} = $name;
return 1;
};

Object methods are called via:

$object-> name_me ($newname);

.... and Perl considerately passes $object as the first param in @_,
later to be shifted into $self. Note that the return value can be thrown
away. The method acts on the $object passed in.

BUT, new -- an object constructor -- is, by definition, used to make a
new object. So, an object of the desired class may not be available yet.
So, new is generally a class method, expecting different params:

package Bottle;

sub new {
my $class = shift;
my $name = shift;

my $self = {};
$self->{NAME} = $name;
bless ($self, $class);
return $self;
};

.... which is called with a completely different syntax, though they may
look similar:

my $object = Bottle->new($name);

It may be more clear to use this alternate syntax, with the same effect:

my $object = new Bottle ($name);

.... or even:

my $object = new Bottle $name;

In any case, the effect is the same. The $class (Bottle) is what is
passed as the first param in @_, to be used to bless the new object. The
object is what is returned by the method.

Two key points of OO technique bear underlining:

* The $object is (usually) a reference to an anonymous hash. Inside our
methods above, we may assign this reference to $self but the reference
still points to a single "thing". With conventional subs, we generally
pass a param and act on its value only; the original param is untouched.
The intent of OO technique is to act on the object directly.

* It all hinges on bless(). The purpose of the new method is to bless
$self, the reference to the anon hash -- to tell Perl to associate
$class with the underlying object. Future calls, say, to name_me or any
other method depend on Perl looking at $object, determining $class, and
going to get the appropriate method.

This may or may not answer your question. If not, don't hesitate to try
again. However, bear in mind my advice about finding a translator. It's
difficult enough for two native speakers of English, both proficient in
Perl, to agree on the exact terms used to describe or explain it.
 
U

Uri Guttman

XC> Most methods are object methods. They are expect params of the form:

XC> package Bottle;

XC> sub name_me {
XC> my $self = shift;
XC> my $name = shift;

XC> ... and Perl considerately passes $object as the first param in @_,
XC> later to be shifted into $self. Note that the return value can be thrown
XC> away. The method acts on the $object passed in.

XC> sub new {
XC> my $class = shift;
XC> my $name = shift;

it is much simpler and more consistant to say that the class or object
is always passed to any method as its first argument. it is the act of
making a method call (class or object doesn't matter) that does this.

XC> It may be more clear to use this alternate syntax, with the same effect:

XC> my $object = new Bottle ($name);

no, that is considered a bad idea. it is deprecated in the docs and was
even mentioned recently here. i always forget which doc discusses why
indirect method calls are bad.

XC> In any case, the effect is the same. The $class (Bottle) is what is
XC> passed as the first param in @_, to be used to bless the new object. The
XC> object is what is returned by the method.

if you always use a direct call then the rule is even easier. the part
before the -> is ALWAYS passed as the first argument. it can be either
an object or a class name. simple.

XC> Two key points of OO technique bear underlining:

XC> * The $object is (usually) a reference to an anonymous hash. Inside our

no. it is always a blessed reference. what reference type is independent
and there are reasons to use types other than hashes. inside-out objects
usually use blessed scalar refs which actually have no data in
them. again this topic has been discussed here many times.

XC> methods above, we may assign this reference to $self but the reference
XC> still points to a single "thing". With conventional subs, we generally
XC> pass a param and act on its value only; the original param is untouched.
XC> The intent of OO technique is to act on the object directly.

not if you pass a ref param to a sub. even you discussed this in the
threads about @_, aliasing and pass by ref/value. the real diff is that
objects are always passed as a ref since only refs can be blessed. so in
general method operate on data in the object and can modify it. plain
subs can be passed anything and they may or may not modify its args
depending on the API and such.

XC> * It all hinges on bless(). The purpose of the new method is to bless
XC> $self, the reference to the anon hash -- to tell Perl to associate
XC> $class with the underlying object. Future calls, say, to name_me or any

s/object/class/. blessing a ref makes it know what class it belongs too
and the ref is now an object.

uri
 
X

Xiong Changnian

Abigail said:
Xiong Changnian ([email protected]) wrote on MMMMCMLXIII September
MCMXCIII in <URL:||
|| BUT, new -- an object constructor -- is, by definition, used to make a
|| new object.

No. 'new' doesn't so by definition....

What you mean to say is that "new" is not a reserved keyword; you're
right: it's arbitrarily chosen.

An object constructor is used to make a new object and in my sample code
I have /defined/ new to be an object constructor. My method new is, by
definition, used to make a new object.

* * *

Why would anyone have a problem with this? I really don't understand why
anyone would quibble in this fashion. What's the point?

I don't subscribe to the paranoid theory of IT: circle the wagons
against vendors who wear the wrong color suits. Still, it's true that
other languages *compete* with Perl -- for time, attention, shelf space,
floor space, podium time, blog buzz, projects, and above all, money.
Competition means we need to be more *attractive* than the next language
community.

We gain nothing at all by behaving like a tank full of sharks. Some
middle manager or student comes along and tosses a bit of chum at us and
we snap viciously at it; now the blood is in the water and we snap at
one another.

Whom do we serve by this uncollegial attitude? We all like to be right
but sometimes that means we need to let other people be right, too.

I promise that nobody will get hired for a job because a manager is
browsing this group and stumbles on a post in which A roots out a subtle
inexactness in B's post. It's not likely that anyone with the power of
the checkbook will be reading this group at all but if he is, his first
thought on seeing such a post will be:

"Oh, I'm glad such a disruptive person isn't in my department, telling
his co-workers what idiots they are."

His second thought may not lie so close to the surface; he'll be slower
to make the judgement but the poison will accumulate, like mercury:

"Perl wizards are jerks; I don't want to do anything in Perl because
then I'd have to hire jerks."

Ladies, gentlemen -- think.

The one greatest service we can do one another -- the greatest honor we
can pay Larry Wall and the small army who have built Perl into such a
fine tool -- is to be civil to one another and helpful to newcomers and
outsiders.

We will not always be correct or exact and if the error is significant,
we'll do well to point it out -- politely. If it is some quibble beneath
the level of importance to someone trying to use the tool to do work, it
is probably better left unsaid. And if some lack of mutual understanding
of the English language opens a gap in our comprehension of another
poster's intent, it's almost surely better not to risk exposure for the
sake of a little ego-feeding.

Please -- I beg of you all -- let's be nice. Let's not be petty. Let's
try to be the sort of people that someone, somewhere, might actually
entrust with a task of some responsibility. Let's try to be the kind of
people who are invited to return, not those who are asked to leave.

Thank you.
 
X

Xiong Changnian

Michele Dondi said:
...can I suggest you try to condense it some more?

I've never been good at that. For one thing, whenever I *do* try to be
terse, someone always seems to sideswipe me with the sort of nitpicking
to which I latterly objected. Personally, I think it should not be
necessary to beat a point to death; if you know enough to object, you're
not getting your information from *me*; if you don't, the issue will
likely not rear its head for quite some time.

In the example, OP was (I believe) stumbling around in the deep dark,
not understanding why new should be a class method. It will be some time
before he wonders if new must always be called new. Meanwhile, my
statement *was* syntactically correct -- so why should we be sitting
here burning up bits as I defend it?

English is ambiguous; that's why we don't program in it. I think it's a
bit silly to hammer anyone for a written English statement that doesn't
appear to reflect the wisdom that one feels must be emphasized.

I really do apologize if you find me verbose. My current career consists
largely of saying the same thing over and over, in the greatest possible
detail.

I offer the consolation that you are not likely to miss anything if you
ignore me -- I might be a tad miffed if you killfiled me, since I am
steadily courteous; but I wouldn't take offense if you skipped over most
of my posts. I'm new to Perl and I shouldn't attempt to lecture my
betters. I'm concious of the fact that I learn a great deal here and I
need to give back to the community, so I field a few questions from
those even newer than myself -- the particular questions that some of us
would prefer *not* to answer, or even read. You may safely assume that
my replies will be long, tedious, repetitive, and overly detailed,
covering much that is taken for granted by the wizards. Worse, perhaps,
you'll sometimes catch me in oversimplification, when I can't imagine it
doing any good to pop open the gearbox and shove the newcomer's face in
it.

If you see me *start* a thread, the topic may be relatively advanced;
I'm asking a question for my own benefit. If you see me *reply*,
especially if the subject header seems poorly chosen, you may want to
assume that the question itself might annoy you (because it's so basic
that I think I can answer it) and also that my reply will bore you
(because I'll try to answer it in enough detail to serve the
uninitiated).

If there is any way in which I, with my limited expertise, may serve you
better, please don't hesitate to ask.

By the way, I tried to email you privately to thank you for my new sig:

Amateurs built Noah's Ark.
Professionals built The Titanic.
 
T

Tad McClellan

Michele Dondi said:
Sometimes I do copy other people's .sig's. But generally I like to
make my own out of witty comments I find in ng's, ml's and web forums.
Hereafter are some. (Probably not all, because I have never
"standardized" the way I write them.)


I was looking through someone else's list of Perlish quotes
just earlier today, and lauching periodic gufaws over
the cubicle wall:

http://pq.tinita.de/?what=fortune

______________________________________________________________________
Yesterday I was in doubt whether to add you to my killfile.
Today, I no longer have that doubt.


Yikes! I was thinking that just upthread...

- Alan J. Flavell in clpmisc, "Re: short script differences"


God, I miss that man!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top