[32886] in Perl-Users-Digest
Perl-Users Digest, Issue: 4164 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 5 21:09:32 2014
Date: Wed, 5 Mar 2014 18:09:08 -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, 5 Mar 2014 Volume: 11 Number: 4164
Today's topics:
FREE SEO Services in India | Free Search Engine Optimi webcolortech@gmail.com
Re: last iteration of a for loop <rweikusat@mobileactivedefense.com>
Re: last iteration of a for loop <ben@morrow.me.uk>
Re: last iteration of a for loop <rweikusat@mobileactivedefense.com>
Re: last iteration of a for loop <ben@morrow.me.uk>
Re: use strict; use warnings; <rweikusat@mobileactivedefense.com>
Re: use strict; use warnings; <news@todbe.com>
Re: use strict; use warnings; <news@todbe.com>
Re: use strict; use warnings; <ben@morrow.me.uk>
Re: use strict; use warnings; <kaz@kylheku.com>
Re: use strict; use warnings; (Tim McDaniel)
Re: use strict; use warnings; <kaz@kylheku.com>
Re: use strict; use warnings; <news@todbe.com>
Re: use strict; use warnings; <news@todbe.com>
Re: use strict; use warnings; <triflemenot@protocol.invalid>
Re: using real objects in constructors <rweikusat@mobileactivedefense.com>
Re: using real objects in constructors <rweikusat@mobileactivedefense.com>
Re: using real objects in constructors <john@castleamber.com>
Re: using real objects in constructors <rweikusat@mobileactivedefense.com>
Re: using real objects in constructors <derykus@gmail.com>
Re: using real objects in constructors <rweikusat@mobileactivedefense.com>
Re: using real objects in constructors <ben@morrow.me.uk>
Re: using real objects in constructors <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 5 Mar 2014 03:21:18 -0800 (PST)
From: webcolortech@gmail.com
Subject: FREE SEO Services in India | Free Search Engine Optimization Services
Message-Id: <3cb6ad0f-e459-4c89-a6bf-b6812a2a2257@googlegroups.com>
FREE SEO Services in India=20
Hurry Up!!=20
First time in India get Completely FREE SEO services. FREE SEO services for=
a month on 3 months package.
OFFER given on promotion of Webcolor Technologies.Webcolor Technologies als=
o Provides Web Design and Deveelopment,Social Media Optimization,Content Wr=
iting,Link Building,Online Reputation Management,Affliate Marketing,Pay per=
Click Services in Hyderabad,India.
Only for LIMITED time.=20
contact now!!
Phone: +91 9052698932
E-Mail: info@webcolortech.com
Web :http://www.webcolortech.com
------------------------------
Date: Wed, 05 Mar 2014 21:22:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: last iteration of a for loop
Message-Id: <87mwh4xrwi.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > OTOH, given/when without some sort of smart matching just isn't that
>> > useful.
>>
>> Trying to be so ueber-smart that the final result is nothing because the
>> problem invariably diffuses into a cloud of nebolous opinions which all
>> have something going for and against them it isn't particular smart in
>> the end. "Do something less ambitious for now and leave the complicated
>> stuff for the future" is IMHO a better approach. Eg, a C
>> switch-statement requires all cases to be integer constants. That's
>> already useful when dealing with functions returning some discrete
>> values and possibly, a default case, eg, fork or <=> or anything which
>> returns 'magic numbers' to indicate different things.
>
> Do you really think so? I don't. Given a choice between (say)
>
> given ($pid) {
> when (undef) {
> die "fork failed";
> }
> when (0) {
> child();
> }
> default {
> parent();
> }
> }
>
> and
>
> if (!defined $pid) {
> die "fork failed";
> }
> elsif ($pid == 0) {
> child();
> }
> else {
> parent();
> }
>
> I think the if/elsif wins on both concision and clarity.
Practically, this will often be
given (fork()) {
when (undef) {
}
when (0) {
}
}
ie, the return value doesn't have to be stored in a variable if it isn't
ever going to be used except for determining the result of the
fork. Even if that becomes
given ($pid = fork() {
when (undef) {
}
when (0) {
}
}
it is still immediately evident that there's one operation which
produces a result and different code blocks dealing with several,
possible outcomes. This may also be the case for an if - elsif - else
cascade but it need not be: Only the last two branches are necessarily
related to each other, any remaining ones could be completely
independent. And there are no keywords chaining subsequent blocks
together because the 'else' is implied in the construct.
[...]
>> Going one step further, one could allow 'string literals'
>> (including interpolation) as well. 'Equality' than mean 'use == if it is
>> an integer constant and eq otherwise'. Additionally dealing with literal
>> regexes shouldn't be a big problem.
>
> You are assuming here that the condition part of the when (or the RHS of
> ~~) can only be a literal? That mostly solves the typing problem, though
> it would necessarily be restricted to *real* literals: a sub returning a
> constant would not do, because constants like that are subject to type
> coercion just like any other values. (That is, just because EPERM was
> defined as an integer constant originally, that does not mean it will
> still be (only) an integer constant by the time we get to compiling the
> when statement.)
Judging from performing some tests with Perl constants, this seems to be
a problem which could be solved. The main issue here seem to be 'string
constants' whose values can be interpreted as valid
numbers. Distinguishing these from numerical constants which acquired a
string representation because of the inner workings of Perl would
require something like a set of 'originally, I was a ...' flags.
------------------------------
Date: Wed, 5 Mar 2014 22:28:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: last iteration of a for loop
Message-Id: <41lkua-0s92.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > You are assuming here that the condition part of the when (or the RHS of
> > ~~) can only be a literal? That mostly solves the typing problem, though
> > it would necessarily be restricted to *real* literals: a sub returning a
> > constant would not do, because constants like that are subject to type
> > coercion just like any other values. (That is, just because EPERM was
> > defined as an integer constant originally, that does not mean it will
> > still be (only) an integer constant by the time we get to compiling the
> > when statement.)
>
> Judging from performing some tests with Perl constants, this seems to be
> a problem which could be solved. The main issue here seem to be 'string
> constants' whose values can be interpreted as valid
> numbers. Distinguishing these from numerical constants which acquired a
> string representation because of the inner workings of Perl would
> require something like a set of 'originally, I was a ...' flags.
Yes, it would. Given that perl has already run out of SvFLAGS, and goes
through some nasty contortions to reuse flag bits wherever it's
unambiguous, I don't think adding new bits just for the sake of given/
when is a good trade-off. Nor is extending the size of the flags field:
that would make every SV larger, reducing the number of SVs which fit in
processor cache, and making every program somewhat slower.
Perl's design is that is has polymorphic types and monomorphic
operators. Trying to create operators which are polymorphic on the types
of their operands never ends well; instead, different operators should
be used, which coerce their operands as appropriate.
Ben
------------------------------
Date: Wed, 05 Mar 2014 22:51:10 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: last iteration of a for loop
Message-Id: <87a9d4xns1.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > You are assuming here that the condition part of the when (or the RHS of
>> > ~~) can only be a literal? That mostly solves the typing problem, though
>> > it would necessarily be restricted to *real* literals: a sub returning a
>> > constant would not do, because constants like that are subject to type
>> > coercion just like any other values. (That is, just because EPERM was
>> > defined as an integer constant originally, that does not mean it will
>> > still be (only) an integer constant by the time we get to compiling the
>> > when statement.)
>>
>> Judging from performing some tests with Perl constants, this seems to be
>> a problem which could be solved. The main issue here seem to be 'string
>> constants' whose values can be interpreted as valid
>> numbers. Distinguishing these from numerical constants which acquired a
>> string representation because of the inner workings of Perl would
>> require something like a set of 'originally, I was a ...' flags.
>
> Yes, it would. Given that perl has already run out of SvFLAGS, and goes
> through some nasty contortions to reuse flag bits wherever it's
> unambiguous, I don't think adding new bits just for the sake of given/
> when is a good trade-off. Nor is extending the size of the flags field:
> that would make every SV larger, reducing the number of SVs which fit in
> processor cache, and making every program somewhat slower.
Keeping additional meta-information about 'Perl constants' supposed to
be used solely while compiling wouldn't necessarily make anything
'larger' at run time.
> Perl's design is that is has polymorphic types and monomorphic
> operators. Trying to create operators which are polymorphic on the types
> of their operands never ends well; instead, different operators should
> be used, which coerce their operands as appropriate.
I don't disagree with statement. What I was writing about was to enable
the Perl compiler to select 'an operator' for a comparison at
compile-time, based on the known type of one of its arguments.That would
be a somewhat more feature-full equivalent to 'multiway conditionals' in
other languages.
And this is certainly perfectly doable.
------------------------------
Date: Thu, 6 Mar 2014 01:44:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: last iteration of a for loop
Message-Id: <9g0lua-74b2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > Yes, it would. Given that perl has already run out of SvFLAGS, and goes
> > through some nasty contortions to reuse flag bits wherever it's
> > unambiguous, I don't think adding new bits just for the sake of given/
> > when is a good trade-off. Nor is extending the size of the flags field:
> > that would make every SV larger, reducing the number of SVs which fit in
> > processor cache, and making every program somewhat slower.
>
> Keeping additional meta-information about 'Perl constants' supposed to
> be used solely while compiling wouldn't necessarily make anything
> 'larger' at run time.
Given that perl has BEGIN and eval/do/require, any information that
might be needed at some later compile time has to also be preserved at
run time. You're right that this information could be kept only for
constants, and could be kept out-of-band in some way so it's only
accessed when it's needed, but this still means increasing the storage
required for a constant sub. constant.pm goes to some trouble to
minimise this storage, because it makes a measurable difference to the
memory usage of Perl programs; reversing that for the sake of a
questionable syntactic shortcut doesn't seem like a good idea.
> > Perl's design is that is has polymorphic types and monomorphic
> > operators. Trying to create operators which are polymorphic on the types
> > of their operands never ends well; instead, different operators should
> > be used, which coerce their operands as appropriate.
>
> I don't disagree with statement. What I was writing about was to enable
> the Perl compiler to select 'an operator' for a comparison at
> compile-time, based on the known type of one of its arguments.
'Selecting an operator at compile time based on the known type of its
arguments' is just another way of saying 'creating an operator which is
polymorphic on the types of its operands'. If 'when' is supposed to
sometimes do string and sometimes numeric comparisons, it should indicate
which is required syntactically, just as == and eq are different
operators.
Ben
------------------------------
Date: Wed, 05 Mar 2014 14:51:10 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: use strict; use warnings;
Message-Id: <87vbvsya01.fsf@sable.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-03-04, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>> Quoth Trifle Menot <triflemenot@protocol.invalid>:
>>>>
>>>> That means programmers write a lot of sloppy programs. It also means
>>>> humans should leave DNA to God.
>>>
>>> I've got a Dr Dawkins for you on line 3...
>>
>> Dr Dawkins' personal system of unverifiable assumptions he holds to be
>> true isn't particularly interesting just because it is the system Dr
>> Dawkins is most comfortable with.
>
> The practice of holding unverifiable assumptions to be true is precisely what
> Dawkins is known for opposing.
According to 'scientific evidence' (and I might as well call this 'ancient
lore' instead, as it rests on testimonials of people supposed to be
considered credible based on who they claim to be), it seems
very probable that I'm mortal. However, if I actually am, I'll certainly
never know this.
------------------------------
Date: Wed, 05 Mar 2014 13:08:14 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: use strict; use warnings;
Message-Id: <lf83o2$ttd$1@news.albasani.net>
On 3/4/2014 17:43, Trifle Menot wrote:
> On Tue, 04 Mar 2014 16:48:00 -0800, "$Bill" <news@todbe.com> wrote:
>
>> So not only do you believe in the supernatural
>
> Doubters say "supernatural" as though faith is baseless superstition.
Exactly what it is. Some idiots 2-3000 years ago write some shit down
and convince a bunch of people that it's true - that's plain ignorant
on the part of the idiots that believe them. Nobody believes in Ra or
Zeus or Thor any more - maybe we just need to wait a few more millennia
before this god of yours fades into oblivion with the rest of the
imposters.
>> but you believe this being to be vengeful
>
> After praying, Samson got vengeance for one of his eyes.
Samsom who? You're going to quote me from one of those fake books that
were written to keep the sheep in line?
> But let's not carry this any further. It's well off topic already. I
> didn't come here to troll. I had a question about printing a string in
> hex, and Rainer gave a helpful answer. But as often happens on usenet,
> one degenerate person went crazy, and things got ugly.
Than why did you bring it up.
------------------------------
Date: Wed, 05 Mar 2014 13:11:44 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: use strict; use warnings;
Message-Id: <lf83ui$psh$1@dont-email.me>
On 3/5/2014 06:51, Rainer Weikusat wrote:
>
> According to 'scientific evidence' (and I might as well call this 'ancient
> lore' instead, as it rests on testimonials of people supposed to be
> considered credible based on who they claim to be), it seems
> very probable that I'm mortal. However, if I actually am, I'll certainly
> never know this.
Very insightful - and I'll never know if you really exist.
------------------------------
Date: Wed, 5 Mar 2014 22:19:37 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use strict; use warnings;
Message-Id: <pgkkua-0s92.ln1@anubis.morrow.me.uk>
Quoth "$Bill" <news@todbe.com>:
> On 3/4/2014 17:43, Trifle Menot wrote:
> > On Tue, 04 Mar 2014 16:48:00 -0800, "$Bill" <news@todbe.com> wrote:
> >
> >> So not only do you believe in the supernatural
> >
> > Doubters say "supernatural" as though faith is baseless superstition.
>
> Exactly what it is. Some idiots 2-3000 years ago write some shit down
> and convince a bunch of people that it's true - that's plain ignorant
> on the part of the idiots that believe them. Nobody believes in Ra or
> Zeus or Thor any more - maybe we just need to wait a few more millennia
> before this god of yours fades into oblivion with the rest of the
> imposters.
1. Stop feeding the troll.
2. Stop being an offensive git. Atheist bigotry is no better than any
other form of religious bigotry.
Ben
------------------------------
Date: Wed, 5 Mar 2014 22:45:26 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: use strict; use warnings;
Message-Id: <20140305144324.87@kylheku.com>
On 2014-03-05, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "$Bill" <news@todbe.com>:
>> On 3/4/2014 17:43, Trifle Menot wrote:
>> > On Tue, 04 Mar 2014 16:48:00 -0800, "$Bill" <news@todbe.com> wrote:
>> >
>> >> So not only do you believe in the supernatural
>> >
>> > Doubters say "supernatural" as though faith is baseless superstition.
>>
>> Exactly what it is. Some idiots 2-3000 years ago write some shit down
>> and convince a bunch of people that it's true - that's plain ignorant
>> on the part of the idiots that believe them. Nobody believes in Ra or
>> Zeus or Thor any more - maybe we just need to wait a few more millennia
>> before this god of yours fades into oblivion with the rest of the
>> imposters.
>
> 1. Stop feeding the troll.
>
> 2. Stop being an offensive git. Atheist bigotry is no better than any
> other form of religious bigotry.
That is false. Rationally founded bigotry is superior to bigotry based on
faith, which makes it somewhat less ugly.
------------------------------
Date: Thu, 6 Mar 2014 00:27:11 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: use strict; use warnings;
Message-Id: <lf8fcv$eo9$1@reader1.panix.com>
In article <pgkkua-0s92.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>1. Stop feeding the troll.
I have skipped most of the posts, but in what I have looked at,
I haven't noticed anything pertaining to Perl.
Unless Perl is a religion, in which case we're practically worshipping
Loki, unless there a Hindu god or Japanese kami for disorganized
ad-hoc evolution of systems.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 6 Mar 2014 01:11:38 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: use strict; use warnings;
Message-Id: <20140305171056.145@kylheku.com>
On 2014-03-06, Tim McDaniel <tmcd@panix.com> wrote:
> In article <pgkkua-0s92.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
>>1. Stop feeding the troll.
>
> I have skipped most of the posts, but in what I have looked at,
> I haven't noticed anything pertaining to Perl.
>
> Unless Perl is a religion, in which case we're practically worshipping
See other thread:
return bless($self, $class);
------------------------------
Date: Wed, 05 Mar 2014 17:12:01 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: use strict; use warnings;
Message-Id: <zXPRu.263$F02.95@fx01.iad>
On 3/5/2014 14:19, Ben Morrow wrote:
>
> 1. Stop feeding the troll.
I'll feed whomever I wish to feed. One can't bring up off topic
religious crap without some sort of chastisement.
> 2. Stop being an offensive git. Atheist bigotry is no better than any
> other form of religious bigotry.
An opinion doesn't constitute bigotry - I tolerate all religions
even if they are pure ignorance. It's been my experience that
atheists are far more tolerant than a lot of theists you'll run
into. Most theists are conservatives - by definition that would
mean less tolerant from my observation.
------------------------------
Date: Wed, 05 Mar 2014 17:23:47 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: use strict; use warnings;
Message-Id: <C6QRu.94$al.68@fx31.iad>
On 3/5/2014 17:11, Kaz Kylheku wrote:
> On 2014-03-06, Tim McDaniel <tmcd@panix.com> wrote:
>> In article <pgkkua-0s92.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>>> 1. Stop feeding the troll.
>>
>> I have skipped most of the posts, but in what I have looked at,
>> I haven't noticed anything pertaining to Perl.
>>
>> Unless Perl is a religion, in which case we're practically worshipping
>
> See other thread:
>
> return bless($self, $class);
Larry is religious - could be some spillover there. ;)
------------------------------
Date: Thu, 06 Mar 2014 01:49:09 +0000
From: Trifle Menot <triflemenot@protocol.invalid>
Subject: Re: use strict; use warnings;
Message-Id: <fujfh9lmkjt0fhu8cth2g9ohpk015juhso@4ax.com>
On Wed, 5 Mar 2014 22:45:26 +0000 (UTC), Kaz Kylheku <kaz@kylheku.com>
wrote:
>On 2014-03-05, Ben Morrow <ben@morrow.me.uk> wrote:
>> 1. Stop feeding the troll.
>>
>> 2. Stop being an offensive git. Atheist bigotry is no better than any
>> other form of religious bigotry.
>
>That is false. Rationally founded bigotry is superior to bigotry based on
>faith, which makes it somewhat less ugly.
"The troll" is not trolling.
I made a few posts mentioning God. Funny how people can freak out when
they see that word. But as I already said, I won't keep the fire going.
So anyone who got heated up, try to cool down.
Later.
------------------------------
Date: Wed, 05 Mar 2014 14:35:28 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using real objects in constructors
Message-Id: <874n3czpan.fsf@sable.mobileactivedefense.com>
Jim Gibson <jimsgibson@gmail.com> writes:
> Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
>> The usual way to construct an instance of a Perl class (I'm aware of)
>> would look somewhat like this:
>>
>> sub new
>> {
>> my ($class, $arg) = @_;
>> my $self;
>>
>> $self->[0] = $arg;
>> return bless($self, $class);
>> }
>>
>> Fairly recently, it occured to me that this can also be accomplished
>> with
>>
>> sub new
>> {
>> my ($class, $arg) = @_;
>> my @self;
>>
>> $self[0] = $arg;
>> return bless(\@self, $class);
>> }
>>
>> Are there any good (or not-so-good) reasons to prefer one over the
>> other?
>
> Couldn't you also do this, then:
>
> sub new
> {
> my ($class, $arg) = @_;
> return bless([$arg], $class);
> }
Obviously. But that's a variant of the first subroutine quoted above as
it uses an anonymous array. And for a real object, I wouldn't be using
$self[0] = ...
but
$self[ARGN] = ...
with some sensible attribute name instead of ARGN and usually leave the
allocation of array indices/ slots for attribute names to other
code. It's just that "Run to the hills --- arrows everywhere!",
http://www.youtube.com/watch?v=M149WTrkNR8
isn't something I'm necessarily fond of because of iself.
------------------------------
Date: Wed, 05 Mar 2014 14:46:51 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using real objects in constructors
Message-Id: <87zjl4ya78.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth tmcd@panix.com:
>> In article <040320141658450958%jimsgibson@gmail.com>,
>> Jim Gibson <jimsgibson@gmail.com> wrote:
>> >
>> >Couldn't you also do this, then:
>> >
>> >sub new
>> >{
>> > my ($class, $arg) = @_;
>> > return bless([$arg], $class);
>> >}
>>
>> so
>>
>> sub new{bless [$_[1]],$_[0]}
>
> The nearest thing to a 'standard' Perl constructor would be
>
> sub new { bless $_[1], $_[0] }
I'd be extremely wary bestowing a blessing on something a stranger
passed to me without even looking at it ...
------------------------------
Date: Wed, 05 Mar 2014 09:01:38 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: using real objects in constructors
Message-Id: <87fvmwu1t9.fsf@castleamber.com>
Henry Law <news@lawshouse.org> writes:
> On 04/03/14 17:18, Rainer Weikusat wrote:
>> it occured to me that this can also be accomplished
>
> I'm very confused, watching my betters arguing over what (to me) looks
> like the hairstyles of the angels on the head of the pin.
>
> What's the matter with the "usual way" which Rainer starts with? If
> it's the usual way, then surely out of deference to whoever is to
> maintain your code, it's the way you should do it?
I think it boils down to using:
my @array = ( 'bar' );
$array[ 1 ] = 'foo';
...
return \@array;
v.s.
my $aref = [ 'bar' ];
$aref->[ 1 ] = 'foo';
...
return $aref;
Which one I use depends on how noisy the rest of the code gets, e.g.
$array[] v.s $aref->[]
and
for ( @array ) v.s. for ( @$aref )
and
baz( \@array ) v.s. baz( $aref )
( Same can be written for %hash v.s. $href).
To me, there's no usual way. And I think it's a must for Perl
programmers to understand both.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Wed, 05 Mar 2014 16:21:42 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using real objects in constructors
Message-Id: <87r46gy5t5.fsf@sable.mobileactivedefense.com>
Henry Law <news@lawshouse.org> writes:
> On 04/03/14 17:18, Rainer Weikusat wrote:
>> it occured to me that this can also be accomplished
>
> I'm very confused, watching my betters arguing over what (to me) looks
> like the hairstyles of the angels on the head of the pin.
Quoting an actual example:
sub new
{
my ($class, $rq, $one_time, $title, $valid_for, $url_prefix, $secrets) = @_;
my @self;
$self[RQ] = $rq;
$self[ONE_TIME] = $one_time;
$self[TITLE] = $title;
$self[VALID_FOR] = $valid_for;
$self[URL_PREFIX] = $url_prefix;
$self[SECRETS] = $secrets;
return bless(\@self, $class);
}
Using an anonymous array, this would become
sub new
{
my ($class, $rq, $one_time, $title, $valid_for, $url_prefix, $secrets) = @_;
my $self;
$self->[RQ] = $rq;
$self->[ONE_TIME] = $one_time;
$self->[TITLE] = $title;
$self->[VALID_FOR] = $valid_for;
$self->[URL_PREFIX] = $url_prefix;
$self->[SECRETS] = $secrets;
return bless($self, $class);
}
Is there something tangible I'd get in return for typing -> -> -> -> ->
->? At the moment, I don't think so. So why do it?
> What's the matter with the "usual way" which Rainer starts with? If
> it's the usual way, then surely out of deference to whoever is to
> maintain your code, it's the way you should do it?
I have no way of knowing anything about the preferences of somebody who
might have to make modifications to this code in future, however, right
now, I am this someone and I prefer not dealing with redundant
punctuation: If it is in the code, then because I'm convinced that it is
good for something (or was convinced that it was good for something by
the time I wrote it) and if I'm not, then, it won't be.
------------------------------
Date: Wed, 5 Mar 2014 13:08:12 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: using real objects in constructors
Message-Id: <04d35a5a-9ac3-40b9-b1cc-58b411cd95ed@googlegroups.com>
On Wednesday, March 5, 2014 8:21:42 AM UTC-8, Rainer Weikusat wrote:
> Henry Law <news@lawshouse.org> writes:
> > On 04/03/14 17:18, Rainer Weikusat wrote:
> >> it occured to me that this can also be accomplished
> >
> > I'm very confused, watching my betters arguing over what (to me) looks
> > like the hairstyles of the angels on the head of the pin.
>
> Quoting an actual example:
>
> sub new
> {
> my ($class, $rq, $one_time, $title, $valid_for, $url_prefix, $secrets) = @_;
> my @self;
> $self[RQ] = $rq;
> $self[ONE_TIME] = $one_time;
> $self[TITLE] = $title;
> $self[VALID_FOR] = $valid_for;
> $self[URL_PREFIX] = $url_prefix;
> $self[SECRETS] = $secrets;
> return bless(\@self, $class);
> }
...
Side issue: maybe a more de-cluttered
hairstyle will suit tiny dance floors:
my $class = shift @_;
my @self;
@self[RQ, ONE_TIME, TITLE, VALID_FOR_URL,
URL_PREFIX, SECRETS] = @_;
bless \@self, $class;
--
Charles DeRykus
------------------------------
Date: Wed, 05 Mar 2014 21:55:03 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using real objects in constructors
Message-Id: <87iorsxqdk.fsf@sable.mobileactivedefense.com>
"C.DeRykus" <derykus@gmail.com> writes:
> On Wednesday, March 5, 2014 8:21:42 AM UTC-8, Rainer Weikusat wrote:
[...]
>> sub new
>> {
>> my ($class, $rq, $one_time, $title, $valid_for, $url_prefix, $secrets) = @_;
>> my @self;
>> $self[RQ] = $rq;
>> $self[ONE_TIME] = $one_time;
>> $self[TITLE] = $title;
>> $self[VALID_FOR] = $valid_for;
>> $self[URL_PREFIX] = $url_prefix;
>> $self[SECRETS] = $secrets;
>> return bless(\@self, $class);
>> }
> ...
>
>
> Side issue: maybe a more de-cluttered
> hairstyle will suit tiny dance floors:
>
> my $class = shift @_;
> my @self;
> @self[RQ, ONE_TIME, TITLE, VALID_FOR_URL,
> URL_PREFIX, SECRETS] = @_;
>
> bless \@self, $class;
This is somewhat maintenance-unfriendly, as evidenced by the appearance
of a 'valid for url' attribute (the argument assignment line
has exactly the same problem, though).
------------------------------
Date: Wed, 5 Mar 2014 22:15:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using real objects in constructors
Message-Id: <g9kkua-0s92.ln1@anubis.morrow.me.uk>
Quoth Henry Law <news@lawshouse.org>:
> On 04/03/14 17:18, Rainer Weikusat wrote:
> > it occured to me that this can also be accomplished
>
> I'm very confused, watching my betters arguing over what (to me) looks
> like the hairstyles of the angels on the head of the pin.
Yep, pretty-much. Rainer's original question was 'is there any
difference here', which is a sensible question to ask; the discussion
only turns silly once it becomes clear the answer is 'no'.
> What's the matter with the "usual way" which Rainer starts with? If
> it's the usual way, then surely out of deference to whoever is to
> maintain your code, it's the way you should do it?
Well, using arrayrefs for objects is not 'usual' in any sense, but
that's a whole different question.
Ben
------------------------------
Date: Wed, 05 Mar 2014 22:34:39 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using real objects in constructors
Message-Id: <87eh2gxojk.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Henry Law <news@lawshouse.org>:
>> On 04/03/14 17:18, Rainer Weikusat wrote:
[...]
>> What's the matter with the "usual way" which Rainer starts with? If
>> it's the usual way, then surely out of deference to whoever is to
>> maintain your code, it's the way you should do it?
>
> Well, using arrayrefs for objects is not 'usual' in any sense, but
> that's a whole different question.
'Usual' was here supposed to refer to 'creating an anonymous object' vs
'returning a reference to a non-anonymous one'. It is also 'usual' that
people abuse hashes in order to emulate 'records'/ 'C structs' because
this seems to be the path of least resistance for creating a 'complex'
object with individual fields which can be accessed by name (which is
then 'usually' not done in favour of wrapping another layer of hashing
around that).
It is not a very good choice for that, however, as there's no
immediateley obvious way of sharing a container object among related
classes while continuing to use 'convenient' attribute names because the
hash provides as a 'flat' 'global namespace', because hashes need more
memory than arrays to store the same number of attributes, because
attribute accesses require run-time hash lookups and because these
accesses usually can't be checked by a compiler.
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4164
***************************************
