[26086] in Perl-Users-Digest
Perl-Users Digest, Issue: 8287 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 28 18:05:31 2005
Date: Thu, 28 Jul 2005 15:05:05 -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 Thu, 28 Jul 2005 Volume: 10 Number: 8287
Today's topics:
Re: copy contructor (Anno Siegel)
Re: How to take acton upon a pattern of nth occurrence? (Hue-Bond)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Jul 2005 21:14:02 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: copy contructor
Message-Id: <dcbhqq$459$1@mamenchi.zrz.TU-Berlin.DE>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXLVIII
> September MCMXCIII in <URL:news:dc909g$gc2$2@mamenchi.zrz.TU-Berlin.DE>:
> () Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> () > Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXLVII
> () > September MCMXCIII in <URL:news:dc5vo5$iuc$1@mamenchi.zrz.TU-Berlin.DE>:
[multiple inheritance]
> Unless you create some kind of has-a relationship. But this 'defect'
> isn't restricted to inside-out objects. Whatever you do, it's going to
> be hard to merge 2 hashes and 3 arrays. (Merging a single hash and a
> single array would still be possible by overloading the object to have
> @{} and %{} magic).
Overloading looks attractive and may work in specific cases, but the
restriction that no two classes be of the same type is too awkward to
be useful in a general class hierarchy. Also de-reference overloading
leads to problems with further inheritance.
> But in practise, the wide-spread practise (sic) of configuring an object
> in the constructor makes it already impossible to do MI without falling
> back on a has-a relationship.
That's an interesting remark, and if I ever get that inheritance paper
written it will make an appearance there in one form or another.
[...]
> () Instead, let me add a thought that is only loosely related. It seems
> () to me that inheritance and encapsulation don't go together (anywhere,
> () not only in Perl) in one respect. When it comes to overriding some
> () of the original methods, you must know how the methods in the base class
> () use (call) each other in order to predict the result. On the other hand,
> () that's an implementation detail that shouldn't concern the inheriting
> () class. I don't see how that can be resolved.
>
> Well, IMO, it's a bad idea to override a proper subset of related methods.
Quite so, but how do you know which methods are related?
> A lot of inheritance is done without overriding any methods - they are
> merely adding functionality, not overriding any. Then you don't have
> the problem you describe above. Furthermore, a lot of overriding is done
> while still calling the overridden method using SUPER.
Sure, a lot can be done without overriding. A lot of useful OO applications
don't even use inheritance. But then, it is only overriding that lets
old code call new code in OO. If you don't need that feature, mere
delegation will do. So, for me, overriding is one of the more interesting
aspects of inheritance.
> But if you have a statistical object with two methods, 'add' to add a
> new number to the set, and 'average' to return the average of the set,
> overriding either of 'add' or 'average', without calling SUPER:: is
> unlikely to work properly.
Funny... the example I had in mind was also a statistical package, where
the user would have to know whether or not ->variance called ->mean before
overriding ->mean to calculate (say) the geometric mean. But the problem
occurs in everyday programming. When inheriting from Tie::Handle, which
of WRITE, PRINT, and PRINTF do you override to get what effect? Only
the source (or experimentation) will tell.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Thu, 28 Jul 2005 19:53:27 +0000 (UTC)
From: "David Serrano (Hue-Bond)" <responder_solo_en_el_grupo@yahoo.es>
Subject: Re: How to take acton upon a pattern of nth occurrence?
Message-Id: <slrndeidvs.6os.responder_solo_en_el_grupo@genus.hue-bond.info>
A. Sinan Unur, mié20050706@14:29:31(CEST):
>
> my $r = substr $s, 0, index $s, 'AAAAAAAAAA';
As always, TIMTOWTDI:
my ($r) = split /A{10}/, $s;
--
David Serrano
------------------------------
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 8287
***************************************
