[30846] in Perl-Users-Digest
Perl-Users Digest, Issue: 2091 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 1 18:09:59 2009
Date: Thu, 1 Jan 2009 15:09:20 -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, 1 Jan 2009 Volume: 11 Number: 2091
Today's topics:
Re: force recursive source filtering <andrex@deadspam.com>
Re: force recursive source filtering <tadmc@seesig.invalid>
Re: hash table usage questions <freesoft12@gmail.com>
Re: hash table usage questions <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 01 Jan 2009 12:17:23 GMT
From: Andrew Schulman <andrex@deadspam.com>
Subject: Re: force recursive source filtering
Message-Id: <bbcpl411f9gn0g7fbb8gj8p17i01feg0mb@4ax.com>
Hi, thanks for your answer.
> AS> I want to apply a source filter, via say Filter::Simple, not just
> AS> to a particular source file, but to all of the source files that
> AS> it may do, require, or use.
>
> did you know that source filtering is considered very evil in the perl
> community?
No, I didn't.
> the main reason is that it can break code easily since it
> doesn't properly (and nothing but perl can parse perl) parse the
> code. perl syntax can change when you use certain modules (many examples
> of this exist) and filtering won't know that and can wreak havoc.
Hm... that's confusing to me, since none of the description that I read said
anything about parsing at all. It is a simple text filter, is it not? And
that's exactly what I want-- a textual filter that will make a small number of
well-defined, parameterized transformations on my code-- roughly speaking,
s/string1/$ENV{A}/g
No syntactical parsing is implied or desired.
Clearly I can modify my code to do this directly, but there are disadvantages to
that approach too, which are particular to my situation and which I won't go
into here. I'd like to understand the feasibility and drawbacks (aside from
performance, which is acceptable in a development environment) of a
comprehensive source code filtering approach.
Andrew.
--
To reply by email, change "deadspam.com" to "alumni.utexas.net"
------------------------------
Date: Thu, 1 Jan 2009 07:43:54 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: force recursive source filtering
Message-Id: <slrnglpi4q.bts.tadmc@tadmc30.sbcglobal.net>
Andrew Schulman <andrex@deadspam.com> wrote:
>> did you know that source filtering is considered very evil in the perl
>> community?
>
> No, I didn't.
>
>> the main reason is that it can break code easily since it
There is the primary drawback.
Source filtering is very likely to be the cause of bugs.
You will likely have enough bugs even without providing them
with an additional way to insert themselves... :-)
>> doesn't properly (and nothing but perl can parse perl) parse the
>> code. perl syntax can change when you use certain modules (many examples
>> of this exist) and filtering won't know that and can wreak havoc.
>
> Hm... that's confusing to me, since none of the description that I read said
> anything about parsing at all.
Do you want to apply the changes to code AND to data?
If not, then you need to parse to know whether it appears in code or in data.
> It is a simple text filter, is it not? And
> that's exactly what I want-- a textual filter that will make a small number of
> well-defined, parameterized transformations on my code-- roughly speaking,
>
> s/string1/$ENV{A}/g
>
> No syntactical parsing is implied or desired.
Perhaps you have not thought this through in enough detail...
Let's say that $ENV{A} = 'foobar';
You want all of these transformations then?
process_string1($arg) ==> process_foobar($arg)
process_string100($arg) ==> process_foobar00($arg)
my $arg = 'string100' ==> my $arg = 'foobar00'
You might say "but none of my code will have those situations".
However, you want to apply this to _all_ code.
Can you say that none of those situations occur in the other people's
code that you are use/require-ing?
> Clearly I can modify my code to do this directly, but there are disadvantages to
> that approach too, which are particular to my situation and which I won't go
> into here.
Then we will be unable to suggest how to work around them without
resorting to the evil that is source code filtering.
> I'd like to understand the feasibility and drawbacks (aside from
> performance, which is acceptable in a development environment) of a
> comprehensive source code filtering approach.
The drawback is in maintainability.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 1 Jan 2009 09:58:58 -0800 (PST)
From: "freesoft12@gmail.com" <freesoft12@gmail.com>
Subject: Re: hash table usage questions
Message-Id: <931c67f8-f843-4dfe-a0a8-7f6834a32a42@z28g2000prd.googlegroups.com>
> The other is, your just plain nuts.
> Its not good enough to spew buzzwords and hypotheticals and expect
> thought to be applied, on your behalf, without respect #1 and humility #2.
>
> sln
asinine answers again and again...
John
------------------------------
Date: Thu, 1 Jan 2009 16:12:19 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: hash table usage questions
Message-Id: <slrnglqfu3.ggv.tadmc@tadmc30.sbcglobal.net>
[ Please provide a proper attribution line when you quote someone ]
freesoft12@gmail.com <freesoft12@gmail.com> wrote:
>> The other is, your just plain nuts.
>> Its not good enough to spew buzzwords and hypotheticals and expect
>> thought to be applied, on your behalf, without respect #1 and humility #2.
>>
>> sln
>
> asinine answers again and again...
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==================================================================
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
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 V11 Issue 2091
***************************************
