[28633] in Perl-Users-Digest
Perl-Users Digest, Issue: 9997 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 22 18:05:56 2006
Date: Wed, 22 Nov 2006 15:05:07 -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 Wed, 22 Nov 2006 Volume: 10 Number: 9997
Today's topics:
Re: accessing numeric variables from textfield input in <perl4hire@softouch.on.ca>
Active State Perl PPM version 4.00 issues <mwendel@brainlink.com>
Re: Can perl create process or thread to do things conc <benmorrow@tiscali.co.uk>
Re: Do I *have* to use 'OOP' to use modules? anno4000@radom.zrz.tu-berlin.de
Re: Do I *have* to use 'OOP' to use modules? anno4000@radom.zrz.tu-berlin.de
Re: Do I *have* to use 'OOP' to use modules? <nospam-abuse@ilyaz.org>
Re: Do I *have* to use 'OOP' to use modules? <abigail@abigail.be>
Re: Do I *have* to use 'OOP' to use modules? <abigail@abigail.be>
Re: Do I *have* to use 'OOP' to use modules? <abigail@abigail.be>
Re: Do I *have* to use 'OOP' to use modules? <abigail@abigail.be>
Re: Do I *have* to use 'OOP' to use modules? anno4000@radom.zrz.tu-berlin.de
Re: Do U use >>>>>perl -e 'use re debug;/REGEX/' so U c <cwilbur@chromatico.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Nov 2006 12:51:51 -0500
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: accessing numeric variables from textfield input in a form
Message-Id: <l609h.14792$tP.3758@read2.cgocable.net>
rallabs@adelphia.net wrote:
> attn.steven.kuo@gmail.com wrote:
>
> Was param($s) the integer you wanted?
>
> --
> Hope this helps,
> Steven
> Steven, Thanks very much, it DID help. Your insight helped me analyze
> the situation in a more logical and sane way. I now realize that the
> root of my problem is the necessity to use param() without any
> arguments. This is because I haven't any idea how many textfields will
> be presented for parsing. (my post contained a form with 2 textfields
> only, but that's an oversimplification of the real situation, in which
> the form presents as little as 1 and as many as 9 textfields.) When
> one uses param with no arguments, one gets the NAMES of the textfields,
> not their contents. The problem is how to get the contents. The
> following is what I tried. Basically, I filled an array with the names
> of the textfields and then tried to use param on each array element in
> turn. I don't understand why it doesn't work, but I at least
> understand why I was getting the error log msg. Here's the guts of my
> script 'parse.cgi':
>
> if (param()){
> my @Parray=param();#these are the contents of textboxes in submitting
> form, 1-9 of them
> my $lenparr=scalar(@Parray);
> print $cc->h2("The number of elements in \@Parray is $lenparr. \n");
> foreach (0..$#Parray) {
> print $cc->h3("\$Parray[$_] is $Parray[$_]. Content of checkbox#$_ is
> param($Parray[$_]).\n");
> }
> The last operation, param($Parray[$_]) , does not yield the contents of
> $Parray[$_], but rather the words " param(side[N] " for pass "N" thru
> the foreach. Yukk. Thank you very much for the help.
> Mike
>
>> rallabs@adelphia.net wrote:
>>
>> (snipped)
>>
>>> two
>>> messages appear in the error log, saying: "$side[0] not numeric in line
>>> 25" and "$side[1] not numeric in line 25".
>> (snipped)
>>
>>
>>> and the second script ('findhyp.cgi') is:
>>> #!/usr/bin/perl -wT
>>> #This is findhyp.cgi
>>> use strict;
>>> use warnings;
>>> use CGI qw(:standard);
>>> $CGI::DISABLE_UPLOADS=1;
>>> $CGI::POST_MAX = 102_400; #100KB
>>> my $cc = new CGI;
>>> print $cc->header;
>>> print $cc->start_html(-title=>'findhyp');
>>> my @percentS;
>>> my $sumsq=0.0;
>>> if (param()){
>>> my @param=param();#these are the two numbers from textboxes on previous
>>> page
>>> foreach my $s (param () ) {
>>> my $ss=param($s);
>>> print $cc->h2("The variable \$s is $ss\n");
>>> $sumsq=$sumsq + param($s)*param($s); #sums up squares of two sides
>>> }
>>> my $squirt=sqrt($sumsq);
>>> print $cc->h2("The variable \$sumsq is $sumsq\n");
>>> print $cc->h2("The variable \$squirt is $squirt\n");
>>> foreach my $s ( param() ) {
>>> my $pcnt=0+param($s);# this is supposed to make the $pcnt variable
>>> numeric according to Castro p24
>>> $percentS[$s] =$pcnt; #we're getting 2 messages in the errorlog saying
>>> "$side[n] not numeric in line 25"; one for each pass thru the foreach
>>
>> You need an integer index to access a particular
>> element of the array @percentS. The value in
>> your $s variable is not an integer.
>>
>> Was param($s) the integer you wanted?
>> If so, try:
>>
>> $percentS[ param($s) ] = $pcnt;
>>
>> instead of
>>
>> $percentS[ $s ] = $pcnt;
>>
>> --
>> Hope this helps,
>> Steven
>
According to 'Official Guide to Programming with CGI.pm' [Lincoln Stein]
this should walk through all the form fields:
foreach $name(param())
{
$value=param($name);
print "The value of $name is $value\n";
}
--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
Perl | MySQL programming for all data entry forms.
"We make web sites work!"
------------------------------
Date: Wed, 22 Nov 2006 14:13:56 -0500
From: Michael Wendel <mwendel@brainlink.com>
Subject: Active State Perl PPM version 4.00 issues
Message-Id: <la79m2ledcodq0dfbgc1dg7rnom7a1f3j5@4ax.com>
Hi All,
I am having some PPM versoin 4.00 ActivePerl Version 5.8.8.819 issues.
I am running Microsoft Windows XP Professional Version 2002 Service
Pack 2. I have full administrative rights on the machine.
I installed ActivePerl (the latest MSI download -
ActivePerl-5.8.8.819-MSWin32-x86-267479.msi
I start up the PPM4 and as expected all the modules are installed in
the Perl AREA. The Site AREA is empty.
Clicking on the View Updatable Modules button shows the following:
Package Name | Area | Installed | Available | Abstract
Achive-Zip perl 1.16 1.18
DBD-SQLite perl 1.12 1.13
DBI perl 1.52 1.53
IO-String perl 1.08 1.06
IO-Zlib perl 1.04 1.01
Tcl perl 0.89-r2 0.89
Term-ReadLine-Perl perl 1.0302-r1 1.0302
Now if I click on any of these selections and choose to upgrade the
module. It installs a new module in site. So I have the old module
in the "perl" AREA and the new one in the "site" AREA.
In addition if you look at the list above. It shows a lower version
of IO-String and IO-Zlib as the available upgrade. That doesn't make
any sense either.
In addition if you read the docs on PPM4 there's some vague reference
that PPM will keep itself updated. Does that include all the
supporting libraries installed in the "perl" AREA?
Also, if you go to the PPM Preferences Dialog it shows the "site" and
"perl" AREA. The is no way to unlock the "perl" AREA in order to
upgrade these modules appropriately.
My next question is - How can I give myself permissions to modify the
"perl" AREA directly? And if I do this and install the upgrades for
these modules is the PPM going to break?
Lastly if I leave the "perl" AREA as is and install all the upgraded
and new modules in the "site" AREA, will I run into module conflicts
by having one verison of a module installed in the "perl" AREA and
another verision of the module in the "site" AREA?
Thank you in advance for any assistance.
Thank You,
Michael Wendel
------------------------------
Date: Wed, 22 Nov 2006 04:23:52 +0000
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Can perl create process or thread to do things concurrently?
Message-Id: <ovvc34-gc2.ln1@osiris.mauzo.dyndns.org>
Quoth quakewang@mail.whut.edu.cn:
> hi,
>
> Can perl create process
perldoc -f fork
> or thread
perldoc threads
> to do things concurrently?
>
> like "fork"?
Oh, so you do know what fork is. Why didn't you just look it up then?
> seems the <<camel book>> did not say about it.
The camel book has a whole chapter on IPC, including how to use fork.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off
the shoulder of Orion; I watched C-beams glitter in the dark near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. benmorrow@tiscali.co.uk
------------------------------
Date: 22 Nov 2006 19:08:25 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <4sjlh9F107nueU1@mid.dfncis.de>
Abigail <abigail@abigail.be> wrote in comp.lang.perl.misc:
> anno4000@radom.zrz.tu-berlin.de (anno4000@radom.zrz.tu-berlin.de) wrote
> on MMMMDCCCXXX September MCMXCIII in <URL:news:4shcu7Fvs7o3U1@mid.dfncis.de>:
> "" Ben Morrow <benmorrow@tiscali.co.uk> wrote in comp.lang.perl.misc:
> "" >
> "" > Quoth anno4000@radom.zrz.tu-berlin.de:
> "" > >
> "" > > Here lies the objective advantage of inside-out classes: They
> "" > > are freely inheritable (can be made base classes, without conflict)
> "" > > by any other class, inside-out or not.
> "" >
> "" > And, almost more importantly, can subclass any other class, inside-out
> "" > or not. That is, given a random class Foo whose implementation I am not
> "" > privy to, I can create an inside-out subclass Bar that definitely
> "" > doesn't tread on Foo's internals. Of course, I can only get at Foo's
> "" > attributes through Foo's public methods, but I should be doing that
> "" > anyway.
> ""
> "" I believe you mean the technique where one uses the otherwise
> "" unused object proper to hold an actual object of the parent
> "" class?
> ""
> "" I don't consider that an essential property of inside-out classes
> "" but rather a (useful) quirk.
>
> Believe me, the ability of inheriting from any class, regardless of its
> implementation was an essential requirement when designing inside-out objects.
>
> "" For one, it renders your class non-inside-out. It touches, err...
> "" de-references its body (the parent class' accessors do) and is thus
> "" in a state of sin. The result can no longer be used as a base class
> "" by anything that isn't compatible with Foo in the usual sense.
>
> Yes, and? Sure, Foo lives in a state of sin from an IOO point of view,
> but the assumption is that you don't control Foo. You got Foo from CPAN
> or your cow-orker. You control Bar. Now, anyone subclassing Bar (say,
> a class Baz) is either an inside-out object, or it isn't. If it is,
> it doesn't care how Foo is implemented, so there's no problem. If it
> isn't, then Baz itself is living 'in a state of sin'. The restrictions
> that are imposed on Baz are done by Foo, not by Bar.
A valid analysis, but I'm thinking not so much in logical but in
psychological or, if you will, marketing terms. Why will IOO
(thanks for the abbreviation) become the standard class implementation
method?
Because the developer of a general purpose class for, say, CPAN (the
market place) wants to avoid everything that might stop a potential
user from using the code. The standard hash implementation allows
other hash-based classes quick-and-dirty inheritance, all others have
to go through contortions to enable full or partial inheritance. Other
implementations tend to be even more restrictive. Only IOO classed are
free of such restrictions, and that makes a *strong* point. Obviously,
I'm only speaking of use by subclassing, other uses of a class are
not impeded by implementation.
On the other hand, a developer who has decided to use IOO is unlikely
to implement the class by subclassing a non-IOO class. That would
spoil the advantage. That's why I consider "upwards inheritablility"
of IOO a more important feature than "downwards inheritablility" for
public classes.
Authors of classes not meant for publication have different criteria,
but they don't decide the race. And even then, I bet most of those
who in fact inherit from a non-IOO class do it "until an IOO-implemen-
tation becomes available".
> "" Also, this technique can only be applied once, multiple inheritance
> "" from non-inside-out classes requires other means.
>
> As noted in another post, MI is almost impossible in Perl if you don't
> control the classes you inherit from. And that has less to do with the
> implementation of the classes, but more with the fact that everyone and
> his donkey makes the mistake of writing methods that do two unrelated
> tasks: constructing an object and initializing an object. Almost all 'new'
> methods construct an object, and then stuff the object with attributes.
> This is what makes MI almost impossible.
Yes, but that is orthogonal to the type of class. All classes can benefit
from separate creation and initialization (which doesn't mean you can't
have a method that does both).
It is a fundamental fact at least in Perl OO that you need a separate
initializer to do multiple inheritance. You can create an object only
once, but you must initialize it for every class on its @ISA tree.
It is strange that this should have escaped Perl's OO culture for so
long. It must be because inheritance in Perl is (was) cumbersome in
the first place, so it doesn't play the part it could.
Anno
------------------------------
Date: 22 Nov 2006 19:22:16 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <4sjmb8F107nueU2@mid.dfncis.de>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote in comp.lang.perl.misc:
> [A complimentary Cc of this posting was sent to
>
> <anno4000@radom.zrz.tu-berlin.de>], who wrote in article
> <4sh529Fvt13sU1@mid.dfncis.de>:
> > > > $val = $o->__attr_get($a_name);
> > > > $o->__attr_set($a_name, $val);
> > > >
> > > > $val = $o->__attr_get_($superclass_name, $a_name); # Allow
> "SUPER" as well
> > > > $o->__attr_set_($superclass_name, $a_name, $val); # Likewise
> > > >
> > > $class->__attr__def__($a_name [, $accessor_method, $mutator_method] );
> > >
> > > with default $accessor_method, $mutator_method keeping the attribute
> > > in some appropriate out-of-band location ($class-dependent). So one
> > > could even encode this into ->import, thus making
> > >
> > > use attr qw(list of attribute names);
> > >
> > > work...
>
> > To answer your question from the parent posting, "Why not do it this
> > way" I'd first have to see how well the scheme works in practice.
>
> Hmm, I hoped that somebody *knows* what an attribute *is*, so is able
> to see whether the API is sufficient...
I don't doubt its sufficiency (though an lvalue accessor might be
added). Like Abigail I see potential problems in usability.
> > Another question is: It's implemented as a pragma, so people are
> > free to build their classes that way or not. Does that matter?
> > This is the problem of many excellent CPAN modules in the Class::
> > and Object:: spaces: They work well and solve many problems -- in
> > a world where everybody uses them.
>
> I need to think about it more...
>
> > Here lies the objective advantage of inside-out classes: They
> > are freely inheritable (can be made base classes, without conflict)
> > by any other class, inside-out or not.
>
> Why you think this is not applicable to the scheme above?
For no particular reason except that inside-out is the only scheme I've
seen yet for which it is. It could depend on implementation details
that aren't yet specified.
Anno
------------------------------
Date: Wed, 22 Nov 2006 20:25:33 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <ek2bnt$k0c$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
<anno4000@radom.zrz.tu-berlin.de>], who wrote in article <4sjmb8F107nueU2@mid.dfncis.de>:
> > > To answer your question from the parent posting, "Why not do it this
> > > way" I'd first have to see how well the scheme works in practice.
> > Hmm, I hoped that somebody *knows* what an attribute *is*, so is able
> > to see whether the API is sufficient...
> I don't doubt its sufficiency (though an lvalue accessor might be
> added). Like Abigail I see potential problems in usability.
> > Why you think this is not applicable to the scheme above?
> For no particular reason except that inside-out is the only scheme I've
> seen yet for which it is. It could depend on implementation details
> that aren't yet specified.
Now I'm completely confused: you say simultaneously that API is
sufficient, and that something depends on implementation details. I
do not see how both can be true...
Thanks,
Ilya
------------------------------
Date: 22 Nov 2006 20:38:12 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <slrnem9d8f.c8.abigail@alexandra.abigail.be>
Ilya Zakharevich (nospam-abuse@ilyaz.org) wrote on MMMMDCCCXXXI September
MCMXCIII in <URL:news:ek110h$2n6d$1@agate.berkeley.edu>:
<> [A complimentary Cc of this posting was sent to
<> Abigail
<> <abigail@abigail.be>], who wrote in article <slrnem7rcb.c8.abigail@alexandra.abigail.be>:
<> > .. Or do you suggest that
<> > ..
<> > .. $val = $obj--->>>{a_name}; # Or whatever the syntax is
<> > ..
<> > .. is *undisputably* preferable to
<> > ..
<> > .. $val = $obj->__get_a_name;
<>
<> > No.
<>
<> > But I do think that
<> >
<> > $val = $.a_name;
<> >
<> > (to borrow a Perl6 syntax) is vastly superiour over either
<> >
<> > $val = $self -> __get_a_name;
<>
<> Enough to influence a choice between languages?
It will certainly have an influence.
Abigail
--
perl -Mstrict -we '$_ = "goto W.print chop;\n=rekcaH lreP rehtona tsuJ";W1:eval'
------------------------------
Date: 22 Nov 2006 20:42:41 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <slrnem9dgs.c8.abigail@alexandra.abigail.be>
Robert 'phaylon' Sedlacek (phaylon@dunkelheit.at) wrote on MMMMDCCCXXXI
September MCMXCIII in <URL:news:456441c1$0$27624$9b4e6d93@newsspool2.arcor-online.net>:
)) Abigail <abigail@abigail.be> wrote
)) > Usability.
)) >
)) > If Larry had decided that Perl wouldn't have variables, but instead
)) > functions 'set' and 'get', we could do the same in Perl as we can now.
))
)) This sounds a lot like you want Perl to behave like some other
)) languages. Ruby or Java perhaps? Personally, I'd hate if Perl would
)) introduce one way to handle attributes. I'm rather glad that I can use
)) Class::BuildMethods, Moose, Class::Accessor::Fast, or my own
)) implementation easily in my objects. Sure Perl 6 will have attributes in
)) a fixed design. But without Perl 5's flexibility over 10 years, how
)) would they have found what's best for most of us?
I fail to understand this argument.
No-one is complaining that Perl takes away flexibility by having regexes
and hashes build in the language, or by not having pointers, but more
restrictive references. Yet people moan that their freedom is taken away
if Perl would have had object instance variables (aka attributes).
Abigail
--
$_ = "\x3C\x3C\x45\x4F\x54"; s/<<EOT/<<EOT/e; print;
Just another Perl Hacker
EOT
------------------------------
Date: 22 Nov 2006 21:09:06 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <slrnem9f2d.c8.abigail@alexandra.abigail.be>
anno4000@radom.zrz.tu-berlin.de (anno4000@radom.zrz.tu-berlin.de) wrote
on MMMMDCCCXXXI September MCMXCIII in <URL:news:4sjlh9F107nueU1@mid.dfncis.de>:
** Abigail <abigail@abigail.be> wrote in comp.lang.perl.misc:
** > anno4000@radom.zrz.tu-berlin.de (anno4000@radom.zrz.tu-berlin.de) wrote
** > on MMMMDCCCXXX September MCMXCIII in <URL:news:4shcu7Fvs7o3U1@mid.dfncis.de>:
** > "" Ben Morrow <benmorrow@tiscali.co.uk> wrote in comp.lang.perl.misc:
** > "" >
** > "" > Quoth anno4000@radom.zrz.tu-berlin.de:
** > "" > >
** > "" > > Here lies the objective advantage of inside-out classes: They
** > "" > > are freely inheritable (can be made base classes, without conflict)
** > "" > > by any other class, inside-out or not.
** > "" >
** > "" > And, almost more importantly, can subclass any other class, inside-out
** > "" > or not. That is, given a random class Foo whose implementation I am not
** > "" > privy to, I can create an inside-out subclass Bar that definitely
** > "" > doesn't tread on Foo's internals. Of course, I can only get at Foo's
** > "" > attributes through Foo's public methods, but I should be doing that
** > "" > anyway.
** > ""
** > "" I believe you mean the technique where one uses the otherwise
** > "" unused object proper to hold an actual object of the parent
** > "" class?
** > ""
** > "" I don't consider that an essential property of inside-out classes
** > "" but rather a (useful) quirk.
** >
** > Believe me, the ability of inheriting from any class, regardless of its
** > implementation was an essential requirement when designing inside-out objects.
** >
** > "" For one, it renders your class non-inside-out. It touches, err...
** > "" de-references its body (the parent class' accessors do) and is thus
** > "" in a state of sin. The result can no longer be used as a base class
** > "" by anything that isn't compatible with Foo in the usual sense.
** >
** > Yes, and? Sure, Foo lives in a state of sin from an IOO point of view,
** > but the assumption is that you don't control Foo. You got Foo from CPAN
** > or your cow-orker. You control Bar. Now, anyone subclassing Bar (say,
** > a class Baz) is either an inside-out object, or it isn't. If it is,
** > it doesn't care how Foo is implemented, so there's no problem. If it
** > isn't, then Baz itself is living 'in a state of sin'. The restrictions
** > that are imposed on Baz are done by Foo, not by Bar.
**
** A valid analysis, but I'm thinking not so much in logical but in
** psychological or, if you will, marketing terms. Why will IOO
** (thanks for the abbreviation) become the standard class implementation
** method?
I don't think I implied that IOO will become the standard class
implementation. In fact, I'm convinced it won't. The vast majority
of the documentation out there telling about objects use hashref based
objects. And that's how people will learn Perl objects, and people don't
have a habit of changing habits.
** Because the developer of a general purpose class for, say, CPAN (the
** market place) wants to avoid everything that might stop a potential
** user from using the code. The standard hash implementation allows
** other hash-based classes quick-and-dirty inheritance, all others have
** to go through contortions to enable full or partial inheritance. Other
** implementations tend to be even more restrictive. Only IOO classed are
** free of such restrictions, and that makes a *strong* point. Obviously,
** I'm only speaking of use by subclassing, other uses of a class are
** not impeded by implementation.
**
** On the other hand, a developer who has decided to use IOO is unlikely
** to implement the class by subclassing a non-IOO class. That would
I beg to differ.
The most important problem that IOO solves is that of subclassing
something of which you don't know the implementation of. Refusing to
subclass a non-IOO class is needlessly restrictive, and you would
have to spend a lot of time rewriting existing code.
I don't consider CPAN to be the "market place". Some people might design
for CPAN, but compared to the number of people that write Perl code,
their numbers are insignificant. The majority of the Perl code that gets
written gets written to solve a problem. Code to solve a problem is code
that I (and with me thousands of others) write every day. And I want to
be able to reuse code, without having to worry how something is implemented.
I want to reuse code that I got from CPAN, that was developed by a coworker
(or something that still needs to be developped by him), that I inherited
from my predecessor, or code that I wrote five years ago.
** to implement the class by subclassing a non-IOO class. That would
** spoil the advantage. That's why I consider "upwards inheritablility"
** of IOO a more important feature than "downwards inheritablility" for
** public classes.
**
** Authors of classes not meant for publication have different criteria,
** but they don't decide the race. And even then, I bet most of those
** who in fact inherit from a non-IOO class do it "until an IOO-implemen-
** tation becomes available".
**
** > "" Also, this technique can only be applied once, multiple inheritance
** > "" from non-inside-out classes requires other means.
** >
** > As noted in another post, MI is almost impossible in Perl if you don't
** > control the classes you inherit from. And that has less to do with the
** > implementation of the classes, but more with the fact that everyone and
** > his donkey makes the mistake of writing methods that do two unrelated
** > tasks: constructing an object and initializing an object. Almost all 'new'
** > methods construct an object, and then stuff the object with attributes.
** > This is what makes MI almost impossible.
**
** Yes, but that is orthogonal to the type of class. All classes can benefit
** from separate creation and initialization (which doesn't mean you can't
** have a method that does both).
**
** It is a fundamental fact at least in Perl OO that you need a separate
** initializer to do multiple inheritance. You can create an object only
** once, but you must initialize it for every class on its @ISA tree.
**
** It is strange that this should have escaped Perl's OO culture for so
** long. It must be because inheritance in Perl is (was) cumbersome in
** the first place, so it doesn't play the part it could.
I think it is always easily dismissed with "you don't want MI anyway".
Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$==-2449231+gm_julian_day+time);do{until($=<$#r){$_.=$r[$#r];$=-=$#r}for(;
!$r[--$#r];){}}while$=;$,="\x20";print+$_=>September=>MCMXCIII=>=>=>=>=>=>=>=>'
------------------------------
Date: 22 Nov 2006 21:25:04 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <slrnem9g0b.c8.abigail@alexandra.abigail.be>
Arved Sandstrom (asandstrom@accesswave.ca) wrote on MMMMDCCCXXIX
September MCMXCIII in <URL:news:ys88h.6345$rB6.355@clgrps13>:
,, "Abigail" <abigail@abigail.be> wrote in message
,, news:slrnem1mdb.bt.abigail@alexandra.abigail.be...
,,
,, > I'm just amazed that people call the absence of elementary construct
,, > (given that you've decided to support OO in the language) a *feature*.
,, > I've never heard anyone advocate Java or C for their lack of native
,, > support for regular expressions or hashes, but people keep considering
,, > the lack of support for object attributes as the best thing since sliced
,, > bread.
,,
,, I don't think Perl is that bad. I fall very strongly on the side of those
,, who say that it's a knowledgeable programmer who should follow a contract,
,, not the language that imposes the contract on him or her. Not only that, but
,, I expect knowledgeable user of my classes, provided that I document them.
,, There are enough, fairly simple, safeguards in Perl OOP to ensure that if a
,, user of an OOP module wants to do something that they oughtn't do, they put
,, some effort into discovering how to do what they shouldn't. And isn't that
,, really the basic issue?
It's not about following contracts.
Heh, if you follow contracts, memory management is easy too, and
there won't be memory leaks. Should be then bemoan Perl doing
memory management for us and robbing us from the freedom malloc
and pointers give us?
No, it turns out that for many programmers, memory management isn't
easy. Having perl do the memory management for you not only reduces
the number of memory management related bugs in the programs, it only
reduces the amount of code a programmer has to write.
If Larry hadn't decide to make OOP an exercise in minimalism and just
had given us attributes, we wouldn't have had the problems we have
now (no compile time checks, unintended clashes, etc), and we could
be even more productive because we would have to write less code.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
------------------------------
Date: 22 Nov 2006 22:15:58 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <4sk0guF108eigU1@mid.dfncis.de>
Abigail <abigail@abigail.be> wrote in comp.lang.perl.misc:
> anno4000@radom.zrz.tu-berlin.de (anno4000@radom.zrz.tu-berlin.de) wrote
> on MMMMDCCCXXXI September MCMXCIII in <URL:news:4sjlh9F107nueU1@mid.dfncis.de>:
> ** Abigail <abigail@abigail.be> wrote in comp.lang.perl.misc:
> ** > anno4000@radom.zrz.tu-berlin.de (anno4000@radom.zrz.tu-berlin.de) wrote
[snip]
> ** A valid analysis, but I'm thinking not so much in logical but in
> ** psychological or, if you will, marketing terms. Why will IOO
> ** (thanks for the abbreviation) become the standard class implementation
> ** method?
>
> I don't think I implied that IOO will become the standard class
> implementation.
I'm not saying you did. I was demonstratively taking an overly
optimistic view to make the point.
> In fact, I'm convinced it won't. The vast majority
> of the documentation out there telling about objects use hashref based
> objects. And that's how people will learn Perl objects, and people don't
> have a habit of changing habits.
At least the process would take many years. Perl 6 will make the point
moot whenever it comes.
> ** Because the developer of a general purpose class for, say, CPAN (the
> ** market place) wants to avoid everything that might stop a potential
> ** user from using the code. The standard hash implementation allows
> ** other hash-based classes quick-and-dirty inheritance, all others have
> ** to go through contortions to enable full or partial inheritance. Other
> ** implementations tend to be even more restrictive. Only IOO classed are
> ** free of such restrictions, and that makes a *strong* point. Obviously,
> ** I'm only speaking of use by subclassing, other uses of a class are
> ** not impeded by implementation.
> **
> ** On the other hand, a developer who has decided to use IOO is unlikely
> ** to implement the class by subclassing a non-IOO class. That would
>
> I beg to differ.
>
> The most important problem that IOO solves is that of subclassing
> something of which you don't know the implementation of. Refusing to
> subclass a non-IOO class is needlessly restrictive, and you would
> have to spend a lot of time rewriting existing code.
>
> I don't consider CPAN to be the "market place". Some people might design
> for CPAN, but compared to the number of people that write Perl code,
> their numbers are insignificant.
True, but their code is influential, at least potentially.
> The majority of the Perl code that gets
> written gets written to solve a problem. Code to solve a problem is code
> that I (and with me thousands of others) write every day. And I want to
> be able to reuse code, without having to worry how something is implemented.
> I want to reuse code that I got from CPAN, that was developed by a coworker
> (or something that still needs to be developped by him), that I inherited
> from my predecessor, or code that I wrote five years ago.
I acknowledged that ...
> ** Authors of classes not meant for publication have different criteria,
[snip]
> ** It is a fundamental fact at least in Perl OO that you need a separate
> ** initializer to do multiple inheritance. You can create an object only
> ** once, but you must initialize it for every class on its @ISA tree.
> **
> ** It is strange that this should have escaped Perl's OO culture for so
> ** long. It must be because inheritance in Perl is (was) cumbersome in
> ** the first place, so it doesn't play the part it could.
>
>
> I think it is always easily dismissed with "you don't want MI anyway".
But you do, once inheritance works without a hitch. You can then have
small general purpose classes to pick and chose from. Labels, messages,
time stamps, locations (a set of coordinates), all with a well-assorted
supply of methods are just a few examples of capabilities you may want to
add to just about any object. We don't have such a library, but with IOO
it could be implemented.
Anno
------------------------------
Date: 22 Nov 2006 13:15:55 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Do U use >>>>>perl -e 'use re debug;/REGEX/' so U can help??
Message-Id: <87lkm3ny90.fsf@mithril.chromatico.net>
>>>>> "robertospara" == robertospara <robertospara@gmail.com> writes:
robertospara> So MONKS OF THE PERL ? [snip 44 redundant question
robertospara> marks] Are you still ALIVE? [snip 50 redundant
robertospara> question marks]
You're behaving like a twit, and so most of the knowledgeable Perl
posters have added you to their kill files. If you want to remedy
this, as much as it can be remedied, you can start by doing the things
Juergen has suggested -- not top posting, not full-quoting, and not
using ridiculous strings of question marks or other punctuation -- and
by reading the Posting Guidelines that are posted here twice a week
and following the advice in them.
If you don't, you're likely to be completely ignored except by trolls
and idiots, and you won't get any useful help here.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
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 9997
***************************************
