[28293] in Perl-Users-Digest
Perl-Users Digest, Issue: 9657 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 28 09:10:16 2006
Date: Mon, 28 Aug 2006 06:10:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 28 Aug 2006 Volume: 10 Number: 9657
Today's topics:
unsolved <ssivasish@yahoo.co.in>
Re: unsolved <David.Squire@no.spam.from.here.au>
Re: What bless() do actually? (Marc Espie)
Re: What bless() do actually? anno4000@radom.zrz.tu-berlin.de
Re: What bless() do actually? <David.Squire@no.spam.from.here.au>
Re: What bless() do actually? <David.Squire@no.spam.from.here.au>
Re: What bless() do actually? (Marc Espie)
Re: What bless() do actually? (Marc Espie)
Re: What bless() do actually? (Marc Espie)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Aug 2006 04:56:42 -0700
From: "sivasish" <ssivasish@yahoo.co.in>
Subject: unsolved
Message-Id: <1156766201.938276.283040@i42g2000cwa.googlegroups.com>
hi any body can help me to write this program
Q.prompt the user to enter two strins of dna.concatenate the two
strings of DNA by appending the second to the first using ".="
operator. print the two strings as concatenated and then print the
second string lined up over its copy at the end of the concatenated
strings. for example
input string are
AAAAAA
TTTTTT
print as AAAAAATTTTTT
TTTTTT
i wrote the code for the first part but not able proceed further.i.e
how to print the above .
------------------------------
Date: Mon, 28 Aug 2006 13:25:06 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: unsolved
Message-Id: <ecunb3$cs2$1@gemini.csx.cam.ac.uk>
sivasish wrote:
> hi any body can help me to write this program
>
> Q.prompt the user to enter two strins of dna.concatenate the two
> strings of DNA by appending the second to the first using ".="
> operator. print the two strings as concatenated and then print the
> second string lined up over its copy at the end of the concatenated
> strings. for example
> input string are
> AAAAAA
> TTTTTT
> print as AAAAAATTTTTT
> TTTTTT
>
> i wrote the code for the first part but not able proceed further.i.e
> how to print the above .
>
Hmmm. Looks like you were on about 5/10 for you assignment, but should
now be heading for 0/10 for cheating.
------------------------------
Date: Mon, 28 Aug 2006 10:30:11 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: What bless() do actually?
Message-Id: <ecugjj$1qi9$1@biggoron.nerim.net>
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:
>> [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.
------------------------------
Date: 28 Aug 2006 12:07:35 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: What bless() do actually?
Message-Id: <4lg4k7F1oc21U1@news.dfncis.de>
Marc Espie <espie@nerim.net> wrote in comp.lang.perl.misc:
> 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:
[...]
> >> 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
------------------------------
Date: Mon, 28 Aug 2006 13:32:34 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: What bless() do actually?
Message-Id: <ecunp2$e2p$1@gemini.csx.cam.ac.uk>
anno4000@radom.zrz.tu-berlin.de wrote:
> Marc Espie <espie@nerim.net> wrote in comp.lang.perl.misc:
>> 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.
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]
>> It has a fairly comprehensive set of object-oriented features, including
>> inheritance with all its needs, introspection, method-calling by name,
>> and polymorphism.
>
> 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
------------------------------
Date: Mon, 28 Aug 2006 13:37:14 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: What bless() do actually?
Message-Id: <ecuo1q$e2p$2@gemini.csx.cam.ac.uk>
David Squire wrote:
> anno4000@radom.zrz.tu-berlin.de wrote:
>>
>> 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.
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
------------------------------
Date: Mon, 28 Aug 2006 12:42:50 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: What bless() do actually?
Message-Id: <ecuoca$1u1e$1@biggoron.nerim.net>
In article <4lg4k7F1oc21U1@news.dfncis.de>,
<anno4000@radom.zrz.tu-berlin.de> wrote:
>> 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.
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...
------------------------------
Date: Mon, 28 Aug 2006 12:57:07 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: What bless() do actually?
Message-Id: <ecup73$1uh8$1@biggoron.nerim.net>
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.
------------------------------
Date: Mon, 28 Aug 2006 13:04:11 +0000 (UTC)
From: espie@lain.home (Marc Espie)
Subject: Re: What bless() do actually?
Message-Id: <ecupkb$1uh8$2@biggoron.nerim.net>
In article <ecuo1q$e2p$2@gemini.csx.cam.ac.uk>,
David Squire <David.Squire@no.spam.from.here.au> wrote:
>David Squire wrote:
>> anno4000@radom.zrz.tu-berlin.de wrote:
>>> 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.
>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. ;-)
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9657
***************************************
