[everyone, please keep posts on list]

> I'm programming a registration & editing produce for my site,
> I want to bind many of same subroutine into a library, and reuse
> these routines in same case.

You don't need to use objects at all. You can just use the package
and module concepts. You can ignore bless and instead of doing

    use Baz;
    $qux = Baz->new;
    $qux->foo;

you can do:

    use Baz;
    Baz::foo;

or

    use Baz;
    .
    .
    package Baz;
    foo;

> I had tried your suggestion, here are several confuse point:
> First, for replacing my line:
>   print $c->displaysub().$a;
> you give me:
>   print $c->displaysub().$ct::a;
> What is $ct? I'm afraid that it is an err in keyboard.

Oops, I meant pt. $pt::a means $a in package pt.

> And when I use the following line in pt.pm
>   our $a;
> system send me a terminated message,my system is Win98+Apache1.3.6 for
win32+perl5 for win32. Perhaps it doesn't support 'our' declaration?

Oops, how quickly I've forgotten pre 5.6.

Use:

    use vars qw($a);

> Additionally, I'm unclearly in bless function & $self={},
> by perl's manual, bless as an inheriate declaration, by your
> explain, $self={} is for defining a group variables what
> inheriated from parents class, isn't it?

bless has got nothing to do with inheritance.

Clear your mind of whatever you have read or thought.

bless does one simple thing. It associates a reference
with a package. That's it.

In appropriate circumstances, eg:

    $foo->bar;

perl looks to see if a reference is blessed, and if so,
retrieves its associated package and acts accordingly.
(In the above case is starts by looking for a bar sub in
that package, and if it finds it, it calls it.)

-------------

$self is just a convention that a) you name the reference
about to be blessed (it doesn't need to be) and b) you
use $self as the variable name. You don't have to name
the reference. You do want to name it, you can call it
$charlie.

-------------

Using {} or [] as the reference rather than \$foo is really
nothing to do with objects either, though, again, it is a
natural for this role.

Consider:

    $x= [];
    $y = [];
    $x->[0] = 'red';
    $x->[1] = 10;
    $y->[0] = 'blue';
    $y->[1] = 20;

Here, the variables have nothing to do with objects.
They are just array references. (Actually, I'm making
an assumption here. Are you familiar with references?
If not, the rest of this probably won't make sense.)
When I dereference the variables, I can store values
in their respective arrays. Nothing unusual here, right?

I can do the same with hashes of course:

    $x= {};
    $x->{color} = 'red';

Again, nothing to do with objects, and simple enough, right?

Now let's create an object from a reference and then use
that object:

    $qux = bless \$foo;

    $qux->foo;

If there was a foo subroutine defined within the current
package, then the last line will work.

(As you can see, even the sub we used before is not
strictly necessary, just the bless.)

Now, we can call any sub defined within the package
into which $qux was blessed:

    $qux->bar;
    $qux->baz;
    $qux->waldo;

but what if we want to store some instance data with
the $qux object, like its color? Hmm. Where to put it.

Hmm. What if we did:

    $qux = bless [];

instead of bless \$qux.

Ah, that's better, we can now say:

    $qux->[0] = 'red';

Bingo, instance data! We could also do:

    $qux = bless {};

    $qux->{color} = 'red';

And that would work too.

Now, imagine that this package inherits from anotherpackage,
which in turn inherits from yetanotherpackage. Let's say, when
you wrote your code, yetanotherpackage already had uses for
[0] thru [2], and [3] was used by anotherpackage. Now you add
your package and you start using [4] thru [6]. Later on, the
author of anotherpackage decides to make use of [4]. Argh.
Ok, s/he could speak to you and agree to use [7] instead, but
then they find out that one of the many other authors that have
written code that inherits from anotherpackage has used [7]
through [10]. Basically, it's a mess.

Using hashes is a much better solution than arrays. It does
not completely eliminate the instance data indexing/naming
clash problem, but it makes it manageable.

hth

Reply via email to