What bless() do actually?

[Davy]

Hi all,

I am new to Perl OO.

I found I have to bless($self) in new subroutine. If not do that, there
is a error: "can't call method on unblessed methods".

I guess if it is before bless($self), only private data pointer to
$self; and after bless($self), method pointer to $self. Is it right? If
not, please give me some intuitive explaination on bless, thanks!

Davy

 

[anno4000]

Hi all,

I am new to Perl OO.

I found I have to bless($self) in new subroutine. If not do that, there
is a error: "can't call method on unblessed methods".

I guess if it is before bless($self), only private data pointer to
$self; and after bless($self), method pointer to $self. Is it right?

It is neither right nor wrong, it's nonsense. You are making up
the terms "private data pointer" and "method pointer" to explain
things, but these terms have no common meaning and explain nothing.

If
not, please give me some intuitive explaination on bless, thanks!

Bless() associates a reference (actually the thing referenced) with
the given class, making the thing an object. When Perl later sees a
reference to the object it can retrieve the class. This is used in
method calls to find the method for a given name and object.

Anno

 

[David Squire]

Hi all,

I am new to Perl OO.

I found I have to bless($self) in new subroutine. If not do that, there
is a error: "can't call method on unblessed methods".

I guess if it is before bless($self), only private data pointer to
$self; and after bless($self), method pointer to $self. Is it right? If
not, please give me some intuitive explaination on bless, thanks!

bless $ref, $classname;

tells the thing referred to by $ref (most commonly a hash) that it is
now an object of class $classname. This means that when it is used
later, $objectref knows which package to look in for its methods etc.

See perldoc -f bless


DS

PS. Perl references are not pointers as in C/C++.

 

[Dr.Ruud]

Davy schreef:

I found I have to bless($self) in new subroutine. If not do that,
there is a error: "can't call method on unblessed methods".

I guess if it is before bless($self), only private data pointer to
$self; and after bless($self), method pointer to $self. Is it right?
If not, please give me some intuitive explaination on bless, thanks!

Read chapter 11 of http://www.perl.org/books/beginning-perl

 

[Jimi-Carlo Bukowski-Wills]

You might do well to remember that classes are cleverly emulated in Perl
but don't actually exist (although I heard they might be available in a
later version)

 

[anno4000]

[please don't top-post. reply moved]

You might do well to remember that classes are cleverly emulated in Perl
but don't actually exist (although I heard they might be available in a
later version)

What do you mean by that?

A Perl class is a (special case of a) package. A package is a (special
case of a) hash. In what sense does the class not exist?

Anno

 

[Jimi-Carlo Bukowski-Wills]

[snippetty snip]

What do you mean by that?

A Perl class is a (special case of a) package. A package is a (special
case of a) hash. In what sense does the class not exist?

Anno

Sorry, for top-posting...

what I mean is that it's not the same as classes in C++...
yes classes can be emulated, but there's no class keyword (in perl5) to
create a class, new is a sub you need to write yourself instead of being a
keyword to instantiate a class and there are not private/public keywords.

Perl was never really an Object Oriented language, it's just that [select
members of] the perl community has been clever enough to emulate it...
compare this will C++ which was specifically designed as OO, or Java, VB,
etc.

The guy who wrote the original question, Davy, has come from a C++
background and seems to expect classes to exist in perl in the same way
they do in C++, but this simply isn't the case... perhaps
"declarative classes with strong encapsulation" are hard coded into perl6,
but most people are still on 5.8.8 or lower.

J

 

[Randal L. Schwartz]

Jimi-Carlo> Perl was never really an Object Oriented language, it's just that [select
Jimi-Carlo> members of] the perl community has been clever enough to emulate it...
Jimi-Carlo> compare this will C++ which was specifically designed as OO, or Java, VB,
Jimi-Carlo> etc.

Oh, the irony of this statement!

Apparently, you're too young to know (or too old to remember) that C++ was
originally just a pre-processor for C, to see if C could support "objects"
without adding anything at all to the language.

In this sense, C++ is to C precisely what Perl5 is to Perl4. It's *just* as
designed, it has just as much capability (I'd argue Perl5 has *more* OO
functionality than C++ because of the introspection) and it's just as usable.

Just because you don't type "c l a s s" in Perl5 doesn't mean you don't have
*true* classes. Get off your high horse there.

Perl5 *is* OO. Perl5 doesn't *emulate* OO. Unless you also say that C++
"emulates" OO, in which case the term means nothing.

print "Just another Perl hacker,"; # the original

 

[Paul Lalli]

what I mean is that it's not the same as classes in C++...
yes classes can be emulated, but there's no class keyword (in perl5) to
create a class, new is a sub you need to write yourself instead of being a
keyword to instantiate a class and there are not private/public keywords.

This may be naïve, but isn't this akin to saying that since Perl
doesn't have the 'float' keyword, it doesn't have floating-point
values? Or that since C doesn't have the 'sub' keyword, it doesn't
have subroutines?

Paul Lalli

 

[anno4000]

[snippetty snip]

What do you mean by that?

A Perl class is a (special case of a) package. A package is a (special
case of a) hash. In what sense does the class not exist?

Anno

Sorry, for top-posting...

what I mean is that it's not the same as classes in C++...

Well, me no speakee C++, so the comparisons are somewhat lost on me.

yes classes can be emulated, but there's no class keyword (in perl5) to
create a class, new is a sub you need to write yourself instead of being a
keyword to instantiate a class and there are not private/public keywords.

Perl was never really an Object Oriented language, it's just that [select
members of] the perl community has been clever enough to emulate it...
compare this will C++ which was specifically designed as OO, or Java, VB,
etc.

It is true, OO is only minimally supported in Perl. In fact, Larry Wall
has been quoted as saying it was an experiment in how little you can get
away with in an OO implementation. There was perhaps little choice
than doing it minimally, given that Perl existed as a procedural
language and had to be kept compatible.

The guy who wrote the original question, Davy, has come from a C++
background and seems to expect classes to exist in perl in the same way
they do in C++, but this simply isn't the case... perhaps
"declarative classes with strong encapsulation" are hard coded into perl6,
but most people are still on 5.8.8 or lower.

The view of OO you get through Perl is certainly different from the
one you get from dedicated OO languages, C++ or otherwise. There is
a degree of freedom in just *how* you use Perl's OO features that
is absent in dedicated languages. Thus, the Exporter module elegantly
solves the problem "how to import the import() routine" by using
inheritance (and nothing else) from Perl's OO repertoire. It can
hardly be called an OO module.

But freedom has its price. Dealing with incompatible types of object
(hash, array, scalar, code, glob) is one of them. Another (related)
one is lack of support for data inheritance. The invention of
Inside-out objects is a recent progress in that area. Having to
invent parts of the mechanism would certainly come as a surprise
to users of a dedicated OO language.

Anno

 

[Jimi-Carlo Bukowski-Wills]

[snippetty snip]

[snippetty snip]
It is true, OO is only minimally supported in Perl. In fact, Larry Wall [snippetty snip]
But freedom has its price. Dealing with incompatible types of object
(hash, array, scalar, code, glob) is one of them. Another (related)
one is lack of support for data inheritance. The invention of
Inside-out objects is a recent progress in that area. Having to
invent parts of the mechanism would certainly come as a surprise
to users of a dedicated OO language.

Anno

I agree.
Davy must be wishing he'd never bothered with Perl now.
Hang in there Davy, it's worth it! Perl is beautiful!

 

[Jimi-Carlo Bukowski-Wills]

This may be naïve, but isn't this akin to saying that since Perl
doesn't have the 'float' keyword, it doesn't have floating-point
values? Or that since C doesn't have the 'sub' keyword, it doesn't
have subroutines?

Paul Lalli

Exactly! "sub" in perl is like "function" in javascript... you can use it
to make named or anonymous subs and/or methods... a functionality which is
not available in c/c++. And whilst we can work which floats in perl, what
we're actually working with is a compound scalar that could also be
interpreted as a string, without any work. This makes it easy to send the
wrong data-type to a routine without testing the data or emulating the
float data-type using an object.

You are right!

 

[Jimi-Carlo Bukowski-Wills]

Jimi-Carlo> Perl was never really an Object Oriented language, it's just that [select
Jimi-Carlo> members of] the perl community has been clever enough to emulate it...
Jimi-Carlo> compare this will C++ which was specifically designed as OO, or Java, VB,
Jimi-Carlo> etc.

Oh, the irony of this statement!

Gulp! [thinks: perhaps I've said something wrong]

Apparently, you're too young to know (or too old to remember) that C++ was
originally just a pre-processor for C, to see if C could support "objects"
without adding anything at all to the language.

I'm not really a C++ programmer, I just assumed it was OO... and I was
right. I assumed that C++ was built on top of C... so... (your use of
the word originally implies that at one time I may have been correct, but
I'm now a dufus! Sorry!)

In this sense, C++ is to C precisely what Perl5 is to Perl4. It's
*just* as designed, it has just as much capability (I'd argue Perl5 has
*more* OO functionality than C++ because of the introspection) and it's
just as usable.

....so yes, you're absolutely correct.

Just because you don't type "c l a s s" in Perl5 doesn't mean you don't
have *true* classes. Get off your high horse there.

But it doesn't alter the fact that a C++ programmer who understands about
classes and inheritance and all that is gonna get a wee bit confused when
he realises that he has to implement the "new" keyword himself. Coming
from a C++ direction (or Java) this must seem really weird!
And if we have *true* classes then how come I need instantiate an object
as an anonymous hash to keep it's data private? If that's not emulation,
it's certainly simulation! Hardly the model of encapsulation...

Perl5 *is* OO. Perl5 doesn't *emulate* OO. Unless you also say that
C++ "emulates" OO, in which case the term means nothing.

OK, this depends on how you want to define OO. When you need to write
what basically amounts to a hack to get yourself to the same place that
any other OO language [that I've used] can get you to with a single
keyword, I think maybe it requires some explaining.

However, I apologise for my ignorance of C++ history. I should probably
know better!

 

[Jimi-Carlo Bukowski-Wills]

[snip]

It's not as much a matter of "implementing the new keyword" as much
one of implementing a constructor, which is something you have to do
in C++ too,

no! You don't HAVE to do it in C++... you can make a class without a
constructor. You can still make a new instance with the new keyword
without having written a constructor.

 

[Jimi-Carlo Bukowski-Wills]

[snip]

Fair enough. The main point still being that it's not as much a matter
of "implementing the new keyword" as much one of implementing a
constructor.


Michele

Yeah... although the main point was really to tell Davy that he shouldn't
expect Perl to be anything like C++ in terms of OO.

 

[Marc Espie]

[snippetty snip]

You might do well to remember that classes are cleverly emulated in Perl
but don't actually exist (although I heard they might be available in a
later version)

What do you mean by that?

A Perl class is a (special case of a) package. A package is a (special
case of a) hash. In what sense does the class not exist?

Anno

Sorry, for top-posting...

what I mean is that it's not the same as classes in C++...

Well, me no speakee C++, so the comparisons are somewhat lost on me.

yes classes can be emulated, but there's no class keyword (in perl5) to
create a class, new is a sub you need to write yourself instead of being a
keyword to instantiate a class and there are not private/public keywords.

Perl was never really an Object Oriented language, it's just that [select
members of] the perl community has been clever enough to emulate it...
compare this will C++ which was specifically designed as OO, or Java, VB,
etc.

It is true, OO is only minimally supported in Perl. In fact, Larry Wall
has been quoted as saying it was an experiment in how little you can get
away with in an OO implementation. There was perhaps little choice
than doing it minimally, given that Perl existed as a procedural
language and had to be kept compatible.

I'm amazed at this discussion.
By your standards, C++ is not an object-oriented language either,
in that you do not have to program in an object-oriented style to
do stuff with it.

There exists object-oriented languages with no classes support. They
generally work by cloning existing objects. Perl5 definitely has
object-oriented functionality based on classes. Even if it calls classes
`packages' and if the method-binding operator is fairly low-level.

It has a fairly comprehensive set of object-oriented features, including
inheritance with all its needs, introspection, method-calling by name,
and polymorphism.

If it lacks anything in that area, it's probably that classes are not really
`objects' on which you can operate. It's a bit awkward to create totally
new classes at run time, compared to (say) smalltalk. But that didn't stop
some people, and since perl is interpreted, it's still possible to do this
kind of stuff.

Perl object-oriented core features are very small. So what ? you don't
need that much. You just have to tie methods to objects. Heck, anonymous
subs were already enough. All the rest is (mostly) syntactic sugar and
performance improvements.

The only place where perl is not oriented-object is that, yes, indeed
everything is not an object, like numbers and such. Most other languages
are that way either. Built-in numbers in C++ are no objects either, and
java has this weird concept of two distinct set of numbers (objects and
non-objects) to avoid performance issue.

 

[anno4000]

Jimi-Carlo Bukowski-Wills <[email protected]> wrote in comp.lang.perl.misc:

[...]

Perl was never really an Object Oriented language, it's just that [select
members of] the perl community has been clever enough to emulate it...
compare this will C++ which was specifically designed as OO, or Java, VB,
etc.

It is true, OO is only minimally supported in Perl. In fact, Larry Wall
has been quoted as saying it was an experiment in how little you can get
away with in an OO implementation. There was perhaps little choice
than doing it minimally, given that Perl existed as a procedural
language and had to be kept compatible.

I'm amazed at this discussion.
By your standards, C++ is not an object-oriented language either,
in that you do not have to program in an object-oriented style to
do stuff with it.

In praxis, C++ is almost exclusively used in OO designs. Perl is
probably used more without its OO features.

There exists object-oriented languages with no classes support. They
generally work by cloning existing objects. Perl5 definitely has
object-oriented functionality based on classes. Even if it calls classes
`packages' and if the method-binding operator is fairly low-level.

You mean "->"? How is it low-level? I mean, what would be a
higher-level version?

It has a fairly comprehensive set of object-oriented features, including
inheritance with all its needs, introspection, method-calling by name,
and polymorphism.

What OO language doesn't have method-calling by name? Polymorphism is
rather a consequence of other features, not an independent feature.

If it lacks anything in that area, it's probably that classes are not really
`objects' on which you can operate. It's a bit awkward to create totally
new classes at run time, compared to (say) smalltalk. But that didn't stop
some people, and since perl is interpreted, it's still possible to do this
kind of stuff.

Oh yes, it is possible to do all kinds of neat OO stuff in a lot of ways.

Perl's problem with OO isn't that you can't do some things (you can),
but that you can do some things in too many ways.

It begins with choosing an object type. In most OO languages, an object
is a struct-like data type. In Perl you get to chose if you want to use
a hash, an array, a scalar or one of the more exotic types, and they
are incompatible unless the programmer(s) take extra efforts. If they
don't a program that uses one class to inherit from the other will
crash an burn. That has so far stopped Perl from developing a useful
class library. Many OO languages are more strongly characterized through
their class library than anything else.

Inside-out classes are promising in this respect. They can be inherited
without restriction by every other class (inside-out or not). They can
also inherit from one (but not more) non-inside-out classes, besides,
of course, arbitrary other inside-out classes.

Maybe Perl will develop a useful class hierarchy on that base, it's
too early to say.

Anno

 

[David Squire]

In praxis, C++ is almost exclusively used in OO designs. Perl is
probably used more without its OO features.

I know plenty of people who write non-OO C++. They are essentially using
it rather than C to get access to the C++ standard library.

[snip]

Polymorphism is rather a consequence of other features, not an independent feature.

That is not the way it is seen (and taught) by many OO folk. It is
common to find textbooks and lecture notes that state something like:

The essential elements of an OO language are inheritance, encapsulation
and polymorphism.

I don't think that polymorphism of the sort obtained by having different
functions with the same name chosen according to their full signature is
a consequence of other OO features (as opposed to polymorphism via
inheritance). Does Perl support this? ... I don't think so.


DS

 

[David Squire]

That is not the way it is seen (and taught) by many OO folk. It is
common to find textbooks and lecture notes that state something like:

The essential elements of an OO language are inheritance,
encapsulation and polymorphism.

Oh, and "abstraction" is often in that list too - but I would be happier
saying that that is a consequence of inheritance (and perhaps polymorphism).


DS

 

[Marc Espie]

What OO language doesn't have method-calling by name? Polymorphism is
rather a consequence of other features, not an independent feature.

C++ doesn't have method-calling by name. Stuff is hard-coded, you can't
treat method-names as first level objects, and call them later. You even
have a specific `pointer to member' notation, and you can build function
adaptors, but you have to get out of your way to do that...

stuff like UNIVERSAL::ISA and $o->$method_name() are sometimes very useful,
but are not present in many other languages.

Read Alexandrescu's _Modern C++ design_, for instance, and compare the
techniques outlined within it to implement some design patterns to how
it's usually done in perl. Granted, perl doesn't have the same performance
trade-offs at all.

I also forgot one important feature of perl: packages are open namespaces.
This makes for a very radical design difference compared to some
other languages...