[26638] in Perl-Users-Digest
Perl-Users Digest, Issue: 8746 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 8 14:05:18 2005
Date: Thu, 8 Dec 2005 11:05:04 -0800 (PST)
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, 8 Dec 2005 Volume: 10 Number: 8746
Today's topics:
Re: A simple inheritance question. (Anno Siegel)
Re: A simple inheritance question. (Anno Siegel)
Re: perl 5.6.1 and Encode.pm <sherm@dot-app.org>
Re: Slow insertion to hashes? xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 8 Dec 2005 17:02:28 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: A simple inheritance question.
Message-Id: <dn9ov4$eus$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 MMMMCDLXXXI
> September MCMXCIII in <URL:news:dn6pql$fl1$1@mamenchi.zrz.TU-Berlin.DE>:
[...]
> ^^ Common wisdom is that Perl has no data inheritance, but that isn't quite
> ^^ true. The problem is that Perl doesn't *support* data inheritance in
> ^^ a meaningful way. If the parent class and the subclass are both hashes,
> ^^ and if you implement inheritance in the standard way (as in your example),
> ^^ there is *too much* data inheritance. The attributes of the subclass are
> ^^ in the same name space as those of the parent, an absurdity in the face of
> ^^ encapsulation. Inside-out objects give every class its own lexical name
> ^^ space, that is their fundamental merit.
>
> Data inheritance with inside-out objects is relatively easy, and can be
> controlled on an attribute by attribute bases. Instead of declaring your
> attribute as:
>
> my %attribute;
>
> use:
>
> our %attribute;
>
> and the attribute is visible from other classes. A subclass can alias
> any attributes it wants to inherit (and leave attributes it doesn't
> want alone).
Interesting how inside-out objects generate a new view on the old
lexical/package distinction, which now appears as private/public (in
reference to object attributes). One more thing to like about inside-out.
[...]
> I'm disliking Class::Std more and more.
See my other followup to you.
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: 8 Dec 2005 17:41:31 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: A simple inheritance question.
Message-Id: <dn9r8b$h3h$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 MMMMCDLXXXI
> September MCMXCIII in <URL:news:dn6qfv$fl1$2@mamenchi.zrz.TU-Berlin.DE>:
> %% <xhoster@gmail.com> wrote in comp.lang.perl.misc:
> %% > Don Gatlin <DG@nowhere.com> wrote:
> %% > > Let me see if I can explain the question in a way to be sensible.
> %% > > The code is at the bottom.
> %% > >
> %% > > I build an Object1 and initalise it with some data with new();
> %% > > I make an instance of it
> %% >
> %% > How can "build"ing it be a different step from making an instance of it?
> %%
> %% A strong case can be made to keep object creation and -initialization
> %% apart in a well-built class. That would make these two different steps,
> %% but making an instance would have to come first, "build"ing later.
> %%
> %% In fact, Class::Std makes this distinction, and the pre-defined name
> %% for the initialization method is indeed ->BUILD.
>
> No! It's very important to realize that Class::Std does NOT make this
> distinction. Making the distinction is very important - any class that
> doesn't (and the vast majority of Perl OO code doesn't) is hard to use in MI.
>
> Now, Class::Std *appears* to make this distinction. However, since BUILD
> is called from the constructor, the distinction is only superfluous; it's
s/superfluous/superficial/ ?
> nothing more than syntactical sugar.
Yes, Class::Std goes back half a step by allowing the user to specify
initialization separately, but calling it in ->new anyway. It tries
to screen the user from the fact that they must be called separately,
but the cost of that screen is probably too high.
It is also slow -- in one example object creation and destruction took
up almost 1/3 of the total cpu. Class::Std is unsuitable for light-weight
objects that are created and thrown away like a mass product.
> Since a few years, I've only used inside-out objects to create classes.
> And my classes only have a constructor if the class doesn't inherit
> from a class that has a constructor. And if the class needs a constructor,
> my constructor looks like:
>
> sub new {bless \do {my $var} => shift}
>
> That's all that needs to be present in the constructor - anything else
> can't be related to constructing the object, and doesn't belong in a
> constructor.
If that bit of code were in UNIVERSAL::new by default, inside-out classes
would be standard without Class::Std. If it had been there right from
the start of Perl OO, we might now have a useful class hierarchy.
Maybe it's not too late. It wouldn't stop anyone from defining their
own ->new, would it?
Of course, inside-out objects hadn't been invented when Perl OO was
introduced, that took a few years. Speaking of which, is there a
single inventor? I know that I have used classes where most of the
info was stored in some lexical $hash{ "$object"}, but I never took
the step of making the central object entirely meaningless. Seeing
the potential in that step is the stroke of genius that is in every
good invention.
I have used Class::Std routinely for a bit, and I'm not entirely happy
either. I guess I'll go to free-wheeling inside-out next, even if it
means I have to write my own destructors and call ->init myself.
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, 08 Dec 2005 11:21:36 -0500
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: perl 5.6.1 and Encode.pm
Message-Id: <m28xuvo8z3.fsf@Sherm-Pendleys-Computer.local>
"Pierre Génieys" <p_geni...@yahoo.fr> writes:
> (I cannot update to a higher version of perl)
That may not be as true as you think...
There are certainly many valid reasons why you might be unable or not allowed
to change /usr/bin/perl.
But that shouldn't keep you from installing another version as well. It's
possible, and not too difficult, to keep as many copies of Perl on your
system as you need to. It's actually fairly common for module authors to do
so, to allow them to test their modules against a variety of Perl versions.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: 08 Dec 2005 17:45:33 GMT
From: xhoster@gmail.com
Subject: Re: Slow insertion to hashes?
Message-Id: <20051208124533.163$WI@newsreader.com>
Jindroush <jindroush.nospam@seznam.cz> wrote:
> xhoster@gmail.com wrote:
> > ##Because I couldn't run your program without file1, I added this
> > ##code. I used 1_000_000 because hey, let's push the limits.
> > {
> > open my $fh, ">$in" or die $!;
> > foreach (1..1_000_000) {
> > print $fh join (" ", map substr(rand(),0,15), 1..6), "\n";
> > };
> > close $fh or die $!;
> > };
> > I don't see anything obviously wrong with your code. The problem is
> > probably with your data (hash key collisions) or with your system
> > (reading the file iteself is very slow, once you get beyong the part
> > that is cached from before. Or some kind of VM problem. Or something
> > else)
> >
> > Generating the file the way I did above, I saw absolutely no slowing at
> > all all the way up to a size of 1_000_000. What do you see if you use
> > my random data rather than your actual data?
>
> It is super fast. Just few seconds (I tried just 100_000 :o) )
>
> The file format is
> 00000000 00000000 00000000 00000000 00000000 filename
>
> first five strings are hexadecimal numbers printed by %08X. Filename is
> unique, there can't be duplicate.
>
> I've tried to replace the key of the hash (from 'lc $fname' to '$cnt'),
> with no significant speed change - it speaks agains the hash collisions
> IMO.
>
> So, I did few tests:
If I understand this right, all the below test are back to using our
data file again, right? And all are >10 times slower than the above
using my on-the-fly generated file?
If that is the case, can you either put our data file on the web somewhere
so that we can reproduce your below results, or write a short segment (like
mine above) which creates a file from random data but formatted like yours
such that it reproduce your results below?
> a) hash key 'lc $fname', only one 8byte string assignment to %H hash -
> 36 seconds
> b) two assignments - 57 seconds
> c) three assigments - 52 seconds
> d) 4 assignments - 50 seconds
> e) 5 assignments - 90 seconds
> f) 6 assignments (including cca 40 bytes long fn) - 120 seconds
> g) same as f, but with '$cnt' hashkey - 106 seconds
> h) same as f, but 5 values replaced with substr( rand(),0,15) - 47
> seconds i) same as f, but 5 values replaced with random 32bit values
> sprintfed as %08X (so 8 byte strings). - 120 seconds
> j) same as f, but 5 values converted to numbers by 'hex'. - 51 seconds.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 8746
***************************************
