[32693] in Perl-Users-Digest
Perl-Users Digest, Issue: 3899 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 3 14:55:57 2013
Date: Wed, 13 Mar 2013 06:09:16 -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 Wed, 13 Mar 2013 Volume: 11 Number: 3899
Today's topics:
Re: Existing module for file browser <jblack@nospam.com>
Re: Existing module for file browser <jblack@nospam.com>
Re: Existing module for file browser <jblack@nospam.com>
Imager::QRCode-ing octet sequences vs. zbarimg(1) <oneingray@gmail.com>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 11 Mar 2013 15:48:06 -0500
From: John Black <jblack@nospam.com>
Subject: Re: Existing module for file browser
Message-Id: <MPG.2ba7ff007fecf30c98976c@news.eternal-september.org>
In article <513b5304$0$6948$e4fe514c@news2.news.xs4all.nl>, rvtol+usenet@xs4all.nl says...
>
> On 2013-03-08 22:37, John Black wrote:
> > Hi, I have some perl code that processes a file or files and I want an easy Windows familiar
> > way for the user to specify the filename. I.e. my users are not really into "command lines".
> >
> > I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
> > has hopefully done to allow the user to use the windows file browser or something like it to
> > traverse the directory tree, find their file and select it. This module would ideally just
> > return a scalar variable containing the filename with path and then my existing code can take
> > it from there. (extra credit to allow the user to select multiple filenames and have them
> > returned in an array...)
> >
> > Does such a thing exist in the public domain? Thanks!
>
> Or tell them to use a specific extension on the file,
> and configure your script to be the default opener for that extension.
>
> Because then they can just doubleclick on the file's name, in their
> favorite file browser, to let your script have it.
>
> You can also implement drag-and-drop, such that if the user drops a
> bunch of files on your icon, your script gets called.
Cool idea thanks. I actually thought of this but 1) I need to use files with standard
extensions like .csv and 2) I think the technology to select files with a browser within a
perl script will come in handy for future projects too.
John Black
------------------------------
Date: Mon, 11 Mar 2013 15:48:47 -0500
From: John Black <jblack@nospam.com>
Subject: Re: Existing module for file browser
Message-Id: <MPG.2ba7ff265e19c14b98976d@news.eternal-september.org>
In article <bh6mj8h38ehjhqkt7jh0lptg7iq0bs95e5@hive.bjoern.hoehrmann.de>, bjoern@hoehrmann.de
says...
>
> * John Black wrote in comp.lang.perl.misc:
> >Hi, I have some perl code that processes a file or files and I want an easy Windows familiar
> >way for the user to specify the filename. I.e. my users are not really into "command lines".
> >
> >I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
> >has hopefully done to allow the user to use the windows file browser or something like it to
> >traverse the directory tree, find their file and select it. This module would ideally just
> >return a scalar variable containing the filename with path and then my existing code can take
> >it from there. (extra credit to allow the user to select multiple filenames and have them
> >returned in an array...)
>
> Sounds like you want one of the Win32:: modules that expose a standard
> function like `GetOpenFileName`, Win32::GUI among them; there probably
> is nothing considerably more off-the-shelf.
This looks promising. Thanks!
John Black
------------------------------
Date: Mon, 11 Mar 2013 15:50:48 -0500
From: John Black <jblack@nospam.com>
Subject: Re: Existing module for file browser
Message-Id: <MPG.2ba7ffa0e660005498976e@news.eternal-september.org>
In article <aaca4f68-074c-4159-8d44-bf5098ac379d@r8g2000vbj.googlegroups.com>, klaus03
@gmail.com says...
>
> On 8 mar, 22:37, John Black <jbl...@nospam.com> wrote:
> > Hi, I have some perl code that processes a file or files and I want an easy Windows familiar
> > way for the user to specify the filename. I.e. my users are not really into "command lines".
> >
> > I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
> > has hopefully done to allow the user to use the windows file browser or something like it to
> > traverse the directory tree, find their file and select it. This module would ideally just
> > return a scalar variable containing the filename with path and then my existing code can take
> > it from there. (extra credit to allow the user to select multiple filenames and have them
> > returned in an array...)
>
> That's the kind of thing the "Windows-standard-File-Explorer-right-
> click-sendto-folder" is made for:
>
> First you write a "hello.bat" file that encapsulates a small perl
> prototype as follows:
>
> hello.bat:
> ----------------------
> @rem = '--*-Perl-*--
> @echo off
> perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
> goto endofperl
> @rem ';
> #!perl
> use strict;
> use warnings;
> for my $file (@ARGV) {
> print "File '$file' has been selected\n";
> # ... do stuff with $file ...
> }
> __END__
> :endofperl
> pause
> ----------------------
>
> Then you put the "hello.bat" file into your sendto-folder.
>
> (on my Windows 7, the sendto-folder is under C:\Users\zzzz\AppData
> \Roaming\Microsoft\Windows\SendTo\, you can use the start-icon on the
> lower-left corner of your screen and type "shell:sendto" to find out
> where the "sendto" folder is on your system...)
>
> Once the "hello.bat" is in your "sendto" folder, just fire up your
> File Explorer, any old directory will do, let's say you go straight to
> your C:\ directory, you select 2 or 3 files and you right-click and
> select sendto...
>
> Under sendto, you will find (amongst other things) a menu "hello.bat"
> -- go straight to that "hello.bat" and voilą: the names of the
> selected files appear in a dos-box.
>
> I hope this helps.
I appreciate this idea but I think its a little kludgier than what I am looking for.
John Black
------------------------------
Date: Wed, 13 Mar 2013 11:40:23 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Imager::QRCode-ing octet sequences vs. zbarimg(1)
Message-Id: <87ehfjmst4.fsf@violet.siamics.net>
[AIUI, discussion of Perl modules is more appropriate for
news:comp.lang.perl.modules. Yet, it appears to be abandoned,
thus cross-posting to news:comp.lang.perl.misc. Cross-posting
to news:alt.barcodes, too, just in case.]
I wonder if QR codes are suitable for encoding arbitrary octet
sequences (AKA 8-bit data)? I've tried the following Perl code,
but it appears that the resulting transformations aren't "8-bit
clean." Somehow, I suspect a QR::Imager fault, although
zbarimg(1) may be responsible. (Unfortunately, the Perl module
itself doesn't provide a decoder.)
Any idea what may be going on?
TIA.
(The leading 51522d436f64653a and the trailing 0a after
"Decoded:" are "QR-Code:" and a newline, respectively. In the
first example, the first three octets in the output, 621d4f,
appear to match the input. Incidentally, the fourth octet has
its most significant bit set.)
$ perl \
89br96tnpoogun68sfh1jkj1sb.perl # "use bytes;" commented out
Blob: 621d4f87d3ae92b60932c96b7f81f3a916faff9b03ae54f97d8163987dc8733df1bd8f8b92fb5317657ee2a0a97eed1f12423cdbfa1a73b3166a39cb4b1c0f43
Image: 123 by 123
Decoded: 51522d436f64653a621d4fc287c393c2aec292c2b60932c3896b7fc281c3b3c2a916c3bac3bfc29b03c2ae54c3b97dc28163c2987dc388733dc3b1c2bdc28fc28bc292c3bb5317657ec3a2c2a0c2a97ec3ad1f12423cc39bc3ba1a73c2b3166a39c38b4b1c0f430a
scanned 1 barcode symbols from 1 images in 0.02 seconds
$ perl \
89br96tnpoogun68sfh1jkj1sb.perl # "use bytes;" in place
Blob: 8abdab3e25ae4e44fbc50d9aedcadfb34b1eb959f78ca306bff1182f00024d1ca9e5d7db8827fdd4ab8169a18130cc3de3b31da82150bff080fe57d591f909cf
Image: 99 by 99
Decoded: 51522d436f64653ac28ac2bdc2ab3e25c2ae4e44c3bbc3850dc29ac3adc38ac39fc2b34b1ec2b959c3b7c28cc2a306c2bfc3b1182f0a
scanned 1 barcode symbols from 1 images in 0.02 seconds
$ LC_ALL=C perl \
89br96tnpoogun68sfh1jkj1sb.perl # "use bytes;" in place
Blob: aba7c3b1e7721a22660308e7a7a7f6cfdb48b18fb2143d823021ece0bb2dde2ed0fe2d4b06fb56c4167e867a1f0ef4f495a46a6efb2ce76621fb58b5bd817605
Image: 123 by 123
Decoded: 51522d436f64653ac2abc2a7c383c2b1c3a7721a22660308c3a7c2a7c2a7c3b6c38fc39b48c2b1c28fc2b2143dc2823021c3acc3a0c2bb2dc39e2ec390c3be2d4b06c3bb56c384167ec2867a1f0ec3b4c3b4c295c2a46a6ec3bb2cc3a76621c3bb58c2b5c2bdc28176050a
scanned 1 barcode symbols from 1 images in 0.03 seconds
$ cat < 89br96tnpoogun68sfh1jkj1sb.perl
use bytes;
use common::sense;
use English;
require Imager::QRCode;
require IPC::Open2;
sub rand_blob (;$) {
my ($len) = @_;
$len
//= 24;
open (my $f, "<", "/dev/urandom")
or die ($OS_ERROR);
binmode ($f);
my $s;
die ($OS_ERROR)
unless (read ($f, $s, $len) == $len);
## .
$s;
}
my $blob
= rand_blob (64);
print ("Blob: ", unpack ("H*", $blob), "\n");
my $qr
= Imager::QRCode->new (qw (mode 8-bit casesensitive 1));
my $img
= $qr->plot ($blob);
print ("Image: ", $img->getwidth (),
" by ", $img->getheight (), "\n");
my ($in, $out);
my $pid
= IPC::Open2::open2 ($in, $out, qw (zbarimg -- -))
or die ($OS_ERROR);
binmode ($in);
binmode ($out);
$img->write ("fh" => $out, "type" => "pnm")
or die ($img->errstr ());
close ($out);
my $dec
= <$in>;
print ("Decoded: ", unpack ("H*", $dec), "\n");
$
--
FSF associate member #7257
------------------------------
Date: Mon, 11 Mar 2013 20:34:47 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87d2v5fzfc.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
[...]
>> if a method the replacement object doesn't implement is called,
>> AUTOLOAD compiles a 'delegation method' of the same name which
>> invokes the method on the DBI object with the same arguments and
>> calls that.
>>
>> That's a perfectly working solution to the problem which needed to be
>> solved in this case. It is very likely not a 'perfectly working' (or
>> any kind of) solution for a lot of other problems which are more or
>> less related to the situation I had to deal with, however, that's no
>> concern of mine at the moment.
>
> Incomplete solutions are useful, yes, especially when one is trying to
> get things done quickly, but they are inherently fragile.
This is a completely 'complete' solution to a specific problem and it
is not at all 'fragile', it just doesn't support some features you
consider important and I don't (because I don't use them). Should
there ever be a need for ...
[...]
> pass one of these delegation objects to something like Storable
> which expects ->can to work properly, or something which expects
> ->isa or (worse) UNIVERSAL::isa to give the right answers.
... passing such an object to
$random_bad_code_downloaded_from_the_net ('bad' here supposed to
mean that it pokes around in the innards of objects it didn't create
which is an 'inherently fragile' way to hack around structural
deficiencies in a class hierarchy) the necessary feature can always be
added.
------------------------------
Date: Mon, 11 Mar 2013 22:17:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <go121a-hd8.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > Incomplete solutions are useful, yes, especially when one is trying to
> > get things done quickly, but they are inherently fragile.
>
> This is a completely 'complete' solution to a specific problem and it
> is not at all 'fragile', it just doesn't support some features you
> consider important and I don't (because I don't use them). Should
> there ever be a need for ...
>
> > pass one of these delegation objects to something like Storable
> > which expects ->can to work properly, or something which expects
> > ->isa or (worse) UNIVERSAL::isa to give the right answers.
>
> ... passing such an object to
> $random_bad_code_downloaded_from_the_net ('bad' here supposed to
You snipped the bit where I pointed out that overload (that is, one of
the core perl pragmas) does this. Unless, of course, you consider perl
itself to be '$random_bad_code_downloaded_from_the_net' (which would
actually explain a lot...).
> mean that it pokes around in the innards of objects it didn't create
> which is an 'inherently fragile' way to hack around structural
> deficiencies in a class hierarchy) the necessary feature can always be
> added.
In a dynamic language like Perl, reflection (that is, structured access
to metadata like 'what is this object' and 'what can it do') is really
important. The whole point of methods like ->can is to allow access to
this metadata *without* poking around in the innards of the object. The
fact the core facilities for reflection are somewhat limited and widely
misused is rather a shame, and one of the advantages of Moose: it
provides an *extensive* metadata interface, including a limited ability
to inquire about non-Moose objects and classes.
Ben
------------------------------
Date: Mon, 11 Mar 2013 22:47:21 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <871ublftae.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > Incomplete solutions are useful, yes, especially when one is trying to
>> > get things done quickly, but they are inherently fragile.
>>
>> This is a completely 'complete' solution to a specific problem and it
>> is not at all 'fragile', it just doesn't support some features you
>> consider important and I don't (because I don't use them). Should
>> there ever be a need for ...
>>
>> > pass one of these delegation objects to something like Storable
>> > which expects ->can to work properly, or something which expects
>> > ->isa or (worse) UNIVERSAL::isa to give the right answers.
>>
>> ... passing such an object to
>> $random_bad_code_downloaded_from_the_net ('bad' here supposed to
>
> You snipped the bit where I pointed out that overload (that is, one of
> the core perl pragmas) does this.
And I've also snipped the bit were you asserted that not implementing
an unneeded feature which seems very dear to do would imply that 'the
code was "done quickly" and without "thinking about it"'. The
pointless invective was as irrelevant to what I wanted to write as the
remark about auto-generating 'operator methods'.
------------------------------
Date: Tue, 12 Mar 2013 01:19:49 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <874nghpg7e.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
[...]
>> it pokes around in the innards of objects it didn't create which is
>> an 'inherently fragile' way to hack around structural deficiencies
>> in a class hierarchy) the necessary feature can always be added.
>
> In a dynamic language like Perl, reflection (that is, structured access
> to metadata like 'what is this object' and 'what can it do') is really
> important. The whole point of methods like ->can is to allow access to
> this metadata *without* poking around in the innards of the object.
To be fair: You have a point regarding overload (which is, after all,
supposed to fiddle with the way 'a class' 'works') and even about
Storable (where alternate options would be 'inconvenient to users')
but 'my inner self' revolts against that: Outside of debuggers, this
kind of stuff shouldn't be necessary and no, I don't have a better
idea myself at the moment.
------------------------------
Date: Tue, 12 Mar 2013 16:29:03 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <fn141a-dq31.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> >> it pokes around in the innards of objects it didn't create which is
> >> an 'inherently fragile' way to hack around structural deficiencies
> >> in a class hierarchy) the necessary feature can always be added.
> >
> > In a dynamic language like Perl, reflection (that is, structured access
> > to metadata like 'what is this object' and 'what can it do') is really
> > important. The whole point of methods like ->can is to allow access to
> > this metadata *without* poking around in the innards of the object.
>
> To be fair: You have a point regarding overload (which is, after all,
> supposed to fiddle with the way 'a class' 'works')
Well, the documented public interface of overload could be implemented
without doing anything unclean, but the result would (apparently) be so
slow as to be unusable. Specifically, the implementation goes to great
lengths to avoid making unoverloaded operations do a method lookup.
> and even about
> Storable (where alternate options would be 'inconvenient to users')
> but 'my inner self' revolts against that: Outside of debuggers, this
> kind of stuff shouldn't be necessary and no, I don't have a better
> idea myself at the moment.
Oh, I agree entirely. Perl 5 OO, once you get past the basic C++ish
stuff, is rather a mess; in part this is because the original design was
something of an experiment in minimalism, and in part because there
wasn't really any satisfactory model to follow, so different people took
the design in different directions without considering how those
directions would end up overlapping. The result is a somewhat confusing
mixture of extreme flexibility and necessary efficiency hacks that often
have unexpected side-effects.
Perl 6's OO model was an attempt to clean all this up, and provide a
system which was less flexible in unimportant ways while allowing the
remaining, useful, flexibility to be used in a way which could both be
implemented efficiently and would allow different ways of extending the
system to interact sensibly. Moose is (basically) a backport of Perl 6
OO to Perl 5; as such it has some untidy edges, partly because not all
objects are Moose objects and partly because there are core interpreter
facilities missing (like a properly extensible dynamic type system, or a
clear distinction between subs and methods), but for systems that make
heavy use of OO the apparent limitations actually end up making it more
flexible.
Ben
------------------------------
Date: Tue, 12 Mar 2013 20:10:36 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87wqtcnzur.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> >> it pokes around in the innards of objects it didn't create which is
>> >> an 'inherently fragile' way to hack around structural deficiencies
>> >> in a class hierarchy) the necessary feature can always be added.
>> >
>> > In a dynamic language like Perl, reflection (that is, structured access
>> > to metadata like 'what is this object' and 'what can it do') is really
>> > important. The whole point of methods like ->can is to allow access to
>> > this metadata *without* poking around in the innards of the object.
>>
>> To be fair: You have a point regarding overload (which is, after all,
>> supposed to fiddle with the way 'a class' 'works')
>
> Well, the documented public interface of overload could be implemented
> without doing anything unclean, but the result would (apparently) be so
> slow as to be unusable. Specifically, the implementation goes to great
> lengths to avoid making unoverloaded operations do a method lookup.
What I was trying to get at is that it is the purpose of overload to
poke around in the innards of 'other classes/ packages', hence, it
must be obviously be excused for doing so.
>> and even about Storable (where alternate options would be
>> 'inconvenient to users') but 'my inner self' revolts against that:
>> Outside of debuggers, this kind of stuff shouldn't be necessary and
>> no, I don't have a better idea myself at the moment.
>
> Oh, I agree entirely. Perl 5 OO, once you get past the basic C++ish
> stuff, is rather a mess;
What I was trying to express is that the UNIVERSAL methods really
shouldn't exist because 'objects' are not supposed to be 'inspected'
by code which isn't a method associated with the particular object in
question. This property is usually known as 'encapsulation'. This is
especially true in 'dynamic languages like Perl' because any property
of 'an object' can change at any time. This includes changes to the
set of messages understood by 'a class', changing the 'response
subroutines' and changing the package association of a particular
reference.
I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
a mess'. I usually undestand this as code language for 'it is
different from $something I happen to be familiar with AND I
ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
constructed in the usual, hackneyed way' ('the usual way' being
'emphasizing the disadvantages of the undesired something while
ignoring the advantages, vice versa for the preferred something' and
resorting to character assassination in order to discredit people who
don't agree with this opinion).
[...]
> Perl 6's OO model was an attempt to clean all this up, and provide a
> system which was less flexible in unimportant ways while allowing the
> remaining, useful, flexibility to be used
As Larry Wall put it: "Second system done right". And insofar the
so-called 'second system effect' is considered, they couldn't possibly
have done it more right (In case someone doesn't understand this: This
means they blew it completely by trying to remedy everything anybody
ever criticized uncritically at the same time, leading to a
horrendous, bloated mess of 'unintegrated' ideas randomly stolen from
a myriad different sources and consequently, a lack-of-design which
takes an eternity to implement and which will be totally obsolete and
abandoned by all people who were once interested in using it except
hardcore fanboys by the time it is considered to be complete -- if
this ever happens).
------------------------------
Date: Tue, 12 Mar 2013 20:29:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <3qf41a-ac61.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
> a mess'. I usually undestand this as code language for 'it is
> different from $something I happen to be familiar with AND I
> ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
> constructed in the usual, hackneyed way' ('the usual way' being
> 'emphasizing the disadvantages of the undesired something while
> ignoring the advantages, vice versa for the preferred something' and
> resorting to character assassination in order to discredit people who
> don't agree with this opinion).
Oh dear. And for a minute there you were being so reasonable...
Ben
------------------------------
Date: Tue, 12 Mar 2013 21:18:49 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87sj40nwp2.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
>> a mess'. I usually undestand this as code language for 'it is
>> different from $something I happen to be familiar with AND I
>> ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
>> constructed in the usual, hackneyed way' ('the usual way' being
>> 'emphasizing the disadvantages of the undesired something while
>> ignoring the advantages, vice versa for the preferred something' and
>> resorting to character assassination in order to discredit people who
>> don't agree with this opinion).
>
> Oh dear. And for a minute there you were being so reasonable...
'Being reasonable' and 'agreeing with opinion X' are two very much
different things.
------------------------------
Date: Tue, 12 Mar 2013 22:40:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <nfn41a-o971.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
> >> a mess'. I usually undestand this as code language for 'it is
> >> different from $something I happen to be familiar with AND I
> >> ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
> >> constructed in the usual, hackneyed way' ('the usual way' being
> >> 'emphasizing the disadvantages of the undesired something while
> >> ignoring the advantages, vice versa for the preferred something' and
> >> resorting to character assassination in order to discredit people who
> >> don't agree with this opinion).
> >
> > Oh dear. And for a minute there you were being so reasonable...
>
> 'Being reasonable' and 'agreeing with opinion X' are two very much
> different things.
The first sentence I quoted I left in for context; it's not directly
pertinent to my reply. My problem is with the rest of the paragraph.
Ben
------------------------------
Date: Wed, 13 Mar 2013 12:05:50 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87ppz3zeqp.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> >> I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
>> >> a mess'. I usually undestand this as code language for 'it is
>> >> different from $something I happen to be familiar with AND I
>> >> ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
>> >> constructed in the usual, hackneyed way' ('the usual way' being
>> >> 'emphasizing the disadvantages of the undesired something while
>> >> ignoring the advantages, vice versa for the preferred something' and
>> >> resorting to character assassination in order to discredit people who
>> >> don't agree with this opinion).
>> >
>> > Oh dear. And for a minute there you were being so reasonable...
>>
>> 'Being reasonable' and 'agreeing with opinion X' are two very much
>> different things.
>
> The first sentence I quoted I left in for context; it's not directly
> pertinent to my reply. My problem is with the rest of the paragraph.
'Your problem' seems to be 'how to turn this away from Perl and into
an [entirely personal] flamewar' and the approach you seem to be
taking, namely, suggesting that people who employ literary devices in
a way you wouldn't, must clearly "be mad [!!2]" and hence, their
opinions can be disregarded, isn't exactly 'new and creative'
(searching for 'people hate perl' on the web easily uncovers texts
which argue that 'Perl can be disregarded' because it was 'clearly
designed by a total madman' based on the style of writing used in some
of the published 'state of the onion' texts) and it is also illogical
(not a great surprise): No statement about me, even if this statement
happened to be true, enables any valid conclusions about any statement
made by me: It could be 'truthful and valid' merely by
coincidence.
NB: This obviously cuts both ways and my conviction that especially a
lot of the more heated criticism about 'Perl OO' one can find on the
web is - ultimatively - manifest xenophobia doesn't imply anything
about the truthfulness of these statements either. But since you were
essentially just repeating the party line, eg, the bit about 'keyword
reuse' which can be found directly in the Perl 6 OO 'design
apocalypse' (alongside 'second system done right' --- isn't it great
how ambiguities in natural language always lend themselves to
'interesting alternate interpretations'?[*] --- Considering my opinion
on Perl 6, 'design apocalypse' seems a very accurate label) a reply
decomposing this text into 'high-level functional units' [a little],
combined with a hint at their purpose, seemed appropriate. Not the
least because of your absolutely marvellous 'demonstration follow-up'.
[*] I need to make an exception for 'It is too minimal' here. This is
just plain nonsense --- the minimum may be too little or not enough
but it can't be 'too minimal' since this already a superlative.
------------------------------
Date: Wed, 13 Mar 2013 12:37:36 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87d2v3zd9r.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> Considering my opinion on Perl 6, 'design apocalypse' seems a very
> accurate label
Nit-picking addition: Since most people don't know any Greek, they
don't understand this as 'relevation' but as some vague remembrance
of the content of the book of relevations, IOW, ragnaroek without the
happy ending (it is really difficult to avoid Greek words which mean
'something completely different' when writing about this, eg,
catastrophe ...).
------------------------------
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 3899
***************************************
