Home > Archive > PERL Beginners > August 2006 > What bless() do actually?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What bless() do actually?
|
|
|
| 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@radom.zrz.tu-berlin.de 2006-08-07, 7:56 am |
| Davy <zhushenli@gmail.com> wrote in comp.lang.perl.misc:
> 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
| |
| Michele Dondi 2006-08-07, 7:56 am |
| On 7 Aug 2006 02:53:03 -0700, "Davy" <zhushenli@gmail.com> wrote:
>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() just adds a 'tag'.
$ perl -le 'print \$r; print bless \$r, "foo"'
SCALAR(0x814fe04)
foo=SCALAR(0x814fe04)
Afterwards perl will know what to do with the bless()ed reference.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
| |
| David Squire 2006-08-07, 7:56 am |
| Davy wrote:
> 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 2006-08-07, 7:56 am |
| 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
--
Affijn, Ruud
"Gewoon is een tijger."
| |
| Jimi-Carlo Bukowski-Wills 2006-08-08, 3:57 am |
| 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)
On Mon, 07 Aug 2006 02:53:03 -0700, Davy wrote:
> 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@radom.zrz.tu-berlin.de 2006-08-08, 3:57 am |
| Jimi-Carlo Bukowski-Wills <jimi@webu.co.uk> wrote in comp.lang.perl.misc:
[please don't top-post. reply moved]
> On Mon, 07 Aug 2006 02:53:03 -0700, Davy wrote:
>
[color=darkred]
> 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 2006-08-08, 7:57 am |
| [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 2006-08-08, 7:57 am |
| >>>>> "Jimi-Carlo" == Jimi-Carlo Bukowski-Wills <jimi@webu.co.uk> writes:
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
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Paul Lalli 2006-08-08, 7:57 am |
| Jimi-Carlo Bukowski-Wills wrote:
> 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=EFve, 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@radom.zrz.tu-berlin.de 2006-08-08, 7:57 am |
| Jimi-Carlo Bukowski-Wills <jimi@webu.co.uk> wrote in comp.lang.perl.misc:
> [snippetty snip]
>
>
> 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 2006-08-08, 9:57 pm |
| On Tue, 08 Aug 2006 13:56:17 +0000, anno4000 wrote:
> Jimi-Carlo Bukowski-Wills <jimi@webu.co.uk> wrote in comp.lang.perl.misc:
[snippetty snip][color=darkred]
> 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 2006-08-08, 9:57 pm |
| On Tue, 08 Aug 2006 06:08:09 -0700, Paul Lalli wrote:
> Jimi-Carlo Bukowski-Wills wrote:
>
> 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 2006-08-08, 9:57 pm |
| On Tue, 08 Aug 2006 05:55:33 -0700, Randal L. Schwartz wrote:
>
> 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  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!
>
> print "Just another Perl hacker,"; # the original
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
> 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See
> PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
| |
| Michele Dondi 2006-08-09, 7:57 am |
| On Tue, 08 Aug 2006 14:53:33 GMT, Jimi-Carlo Bukowski-Wills
<jimi@webu.co.uk> wrote:
>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 when
>he realises that he has to implement the "new" keyword himself. Coming
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, with the difference that in the former case it can have
any name and is called like a class method while in the latter by
*means* of the new keyword.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
| |
| Jimi-Carlo Bukowski-Wills 2006-08-09, 7:57 am |
| [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.
> with the difference that in the former case it can have
> any name and is called like a class method while in the latter by
> *means* of the new keyword.
>
>
> Michele
| |
| Michele Dondi 2006-08-09, 7:57 am |
| On Wed, 09 Aug 2006 12:27:51 GMT, Jimi-Carlo Bukowski-Wills
<jimi@webu.co.uk> wrote:
>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.
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
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
| |
| Marc Espie 2006-08-28, 7:57 am |
| In article <4jrjg1F9e3fvU1@news.dfncis.de>,
<anno4000@radom.zrz.tu-berlin.de> wrote:
>Jimi-Carlo Bukowski-Wills <jimi@webu.co.uk> wrote in comp.lang.perl.misc:
>
>Well, me no speakee C++, so the comparisons are somewhat lost on me.
>
>
>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@radom.zrz.tu-berlin.de 2006-08-28, 7:57 am |
| Marc Espie <espie@nerim.net> wrote in comp.lang.perl.misc:
> In article <4jrjg1F9e3fvU1@news.dfncis.de>,
> <anno4000@radom.zrz.tu-berlin.de> wrote:
[...]
[color=darkred]
>
> 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 2006-08-28, 7:57 am |
| anno4000@radom.zrz.tu-berlin.de wrote:
> Marc Espie <espie@nerim.net> wrote in comp.lang.perl.misc:
>
> 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 2006-08-28, 7:57 am |
| David Squire wrote:
> anno4000@radom.zrz.tu-berlin.de wrote:
>
> 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 2006-08-28, 7:57 am |
| In article <4lg4k7F1oc21U1@news.dfncis.de>,
<anno4000@radom.zrz.tu-berlin.de> wrote:
>
>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...
| |
| Marc Espie 2006-08-28, 7:57 am |
| In article <4lg4k7F1oc21U1@news.dfncis.de>,
<anno4000@radom.zrz.tu-berlin.de> wrote:
>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.
Nonsense. Being able to do things in many ways has always been THE trademark
of the language. I've yet to be stopped by it, and so do lots of people,
since CPAN is thriving with interesting modules, a lot of them showing
very advanced object techniques.
>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.
A useful class library ? ah! then what I use every day isn't useful.
You have everything at your disposal, and it's usually about ten lines
of code to adapt stuff to use an outside class you don't know anything
about.
Focusing on inheritance is a bad design decision in my opinion. Too tight
coupling. Composition is often much better. And you can use the autoloader
to great effect to build new behavior on top of existing classes.
>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.
Well, I don't care too much about clients misusing my code. I focus on
writing useful code, and then if they abuse it, that's their problem, not
mine.
There was a quote in _programming perl_ to the effect that perl doesn't
really need private/public because perl programmers prefer you stay out
of their internals because you politely ask them to, not because you
string a fence with barbed wire around it. I adopted this as my
opinion.
| |
| Marc Espie 2006-08-28, 7:57 am |
| In article <ecuo1q$e2p$2@gemini.csx.cam.ac.uk>,
David Squire <David.Squire@no.spam.from.here.au> wrote:
>David Squire wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
>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).
Personally, I would tend to put `abstraction' at the top.
Inheritance and polymorphism are actually not really needed in many cases.
You can build OO languages without inheritance. Cloning prototype objects
comes to mind.
This kind of behavior is even not too hard to build in perl, and I've
built Object-oriented PostScript code in the past by using that technique.
The only `feature' you need for object-orientation is a way to associate
code with data, namely have an operator so that o->f(args) will call an f
which is dependent on o.
So any language with hashes and anonymous subs leads itself to object-oriented
techniques in a very straightforward way: just let your hashes be objects,
and key the anonymous subs with method names. Everything else, including
using an extra indirection through a `class' to have uniform object behavior
and save memory is just optimization. ;-)
| |
| David Squire 2006-08-28, 7:57 am |
| Marc Espie wrote:
> In article <ecuo1q$e2p$2@gemini.csx.cam.ac.uk>,
> David Squire <David.Squire@no.spam.from.here.au> wrote:
>
>
>
>
>
>
> Personally, I would tend to put `abstraction' at the top.
In terms of importance yes, but is it a fundamental language property or
a something constructed by coding? From a language point of view, it's
about being about to have abstract classes (e.g. pure virtual functions
in C++, interfaces in Java), which to me is all about inheritance.
> Inheritance and polymorphism are actually not really needed in many cases.
>
> You can build OO languages without inheritance. Cloning prototype objects
> comes to mind.
>
> This kind of behavior is even not too hard to build in perl, and I've
> built Object-oriented PostScript code in the past by using that technique.
>
> The only `feature' you need for object-orientation is a way to associate
> code with data, namely have an operator so that o->f(args) will call an f
> which is dependent on o.
>
> So any language with hashes and anonymous subs leads itself to object-oriented
> techniques in a very straightforward way: just let your hashes be objects,
> and key the anonymous subs with method names. Everything else, including
> using an extra indirection through a `class' to have uniform object behavior
> and save memory is just optimization. ;-)
Your definition of OO as no more than "code associated with data" is at
odds with the currently accepted (academic) definition of what an OO
language is. This is not a value judgment, just a statement of current
dogma.
I have a lot of sympathy with your view, but ultimately I think this
argument leads towards the conclusion that all Turing-complete languages
are OO, since you could built such machinery out of them one way or
another. It must surely be a question of what the language natively
supports, rather than what can be built using it.
I think we need to make a distinction between OO languages and OO
techniques. Years ago I wrote a widget set (before I was aware of that
term) for SGI machines in C, using structs with function pointers to
represent "widgets". In retrospect an OO technique, but that does not
make C an OO language.
DS
| |
| Marc Espie 2006-08-28, 7:57 am |
| In article <ecur80$kjl$1@gemini.csx.cam.ac.uk>,
David Squire <David.Squire@no.spam.from.here.au> wrote:
>Your definition of OO as no more than "code associated with data" is at
>odds with the currently accepted (academic) definition of what an OO
>language is. This is not a value judgment, just a statement of current
>dogma.
I disagree. You're talking buzzwords and undergraduate academics.
All the stuff I've seen regarding semantics research and type checking,
for instance, boils down to extending traditional lambda-calculus somehow
to include object constructs.
Any half decent course on language theory/compilation/semantics will have
some reduction towards object = data + associated methods, together with
a discussion of space-constraint optimizations (e.g., vtables) and
type systems and their various limitations.
| |
| anno4000@radom.zrz.tu-berlin.de 2006-08-28, 6:57 pm |
| Marc Espie <espie@nerim.net> wrote in comp.lang.perl.misc:
> In article <4lg4k7F1oc21U1@news.dfncis.de>,
> <anno4000@radom.zrz.tu-berlin.de> wrote:
>
> Nonsense. Being able to do things in many ways has always been THE trademark
> of the language. I've yet to be stopped by it, and so do lots of people,
> since CPAN is thriving with interesting modules, a lot of them showing
> very advanced object techniques.
Quite so. But when you want to use two of them together you must study
both quite carefully to see how that can best be done. It gets worse
with more modules, and the more advanced ones are often hardest to
integrate with others.
Perl's motto TIMTOWTDI shouldn't make us blind to the risks and
drawbacks this approach also has.
>
> A useful class library ? ah! then what I use every day isn't useful.
> You have everything at your disposal, and it's usually about ten lines
> of code to adapt stuff to use an outside class you don't know anything
> about.
>
> Focusing on inheritance is a bad design decision in my opinion. Too tight
> coupling. Composition is often much better. And you can use the autoloader
> to great effect to build new behavior on top of existing classes.
Inheritance is an integral part of OO programming. Without neglecting
other techniques, inheritance ought to be available when it is the right
tool. Using inheritance is not, per se, a bad design decision. A
programmer who does everything through it (or tries to) isn't making
a bad design decision but is following a bad habit.
In Perl inheritance isn't as freely available as it should be.
>
> Well, I don't care too much about clients misusing my code. I focus on
> writing useful code, and then if they abuse it, that's their problem, not
> mine.
The point of inside-out classes isn't protection of object data. That's
a useful side effect. The point is that every class has its own
name space without conflicts with other classes.
Even in a world where every object was standardized to be a hash ref
whose keys and values are used like the fields of a struct, (a very
popular implementation) you can't safely add more fields without knowing
the implementation of the host object. It gets worse when the host
can be of any type.
Inside-out classes are a way to get rid of that dependency. They are
not about protecting your data from malicious users.
> There was a quote in _programming perl_ to the effect that perl doesn't
> really need private/public because perl programmers prefer you stay out
> of their internals because you politely ask them to, not because you
> string a fence with barbed wire around it. I adopted this as my
> opinion.
Roughly: "Perl prefers you to stay outside the living room because you
were not invited, not because it has a shotgun."
That's very well as far as it goes. I, too, am happy to indicate
private routines and methods with a leading underscore and nothing
else.
The problem is that you don't always know when you are entering
someone's living room. Then you find out they do have a shotgun
after all.
Anno
|
|
|
|
|