Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Ovid
--- Eric Wilhelm [EMAIL PROTECTED] wrote:

 
   http://search.cpan.org/~ewilhelm/lambda-v0.0.1/lib/lambda.pm

Combined with that vim shortcut, this is just too cool :)

I'd probably have put it in the Acme:: namespace, though.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/


Re: relative.pm vs import.pm

2007-10-11 Thread Johan Vromans
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] writes:

 unless I read it wrong, it doesn't provide the feature relative.pm
 was written for in the first place, that is loading modules using
 names relative to the current one.

If I understand correctly, that would be

  use import __PACKAGE__;

-- Johan


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Eric Wilhelm
# from Ovid
# on Thursday 11 October 2007 00:54:

I'd probably have put it in the Acme:: namespace, though.

Why?  AFAICT, the Acme stuff isn't typically intended for production 
use.

I plan to use it early and often.

--Eric
-- 
Because understanding simplicity is complicated.
--Eric Raymond
---
http://scratchcomputing.com
---


Re: relative.pm vs import.pm

2007-10-11 Thread A. Pagaltzis
* Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-11 12:10]:
 But this will load *all* the modules below the current one,
 which is not the same thing as loading a set of selected
 modules. Imagine doing this with Plagger ;)

Imagine trying to load all of Plagger’s modules by hand. ;--)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: RFC: String::Smart

2007-10-11 Thread A. Pagaltzis
* Andy Armstrong [EMAIL PROTECTED] [2007-10-10 22:45]:

Nice email address. :-P

 This evening I started playing with String::Smart (the name is
 as provisional as everything else).

Something with “language”, “type”, “quoting” or “escaping” would
be more appropriate I think.

 In general a String::Smart string knows which transformations
 are currently applied to a string and when you ask for a
 particular representation of that string it computes the path
 from the current encoding to the desired encoding and applies
 the transformations in the appropriate order.

Have you seen Tom Moertel’s article on applying Haskell to this?
http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem

See also String::EscapeCage, which was discussed recently on this
list, and which is just as horribly named. :-)  It differs in
that it doesn’t address the chaining you mention, and by hooking
itself into tainting.

And I’m almost positive that I have seen one more module that
tries to address the exact same issue.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: New OO module idea - looking for suggestions

2007-10-11 Thread A. Pagaltzis
* bmillares [EMAIL PROTECTED] [2007-10-10 20:30]:
 I was wondering if there is any interest out there for such a
 animal.

I am not personally interested. Currently, if I use any OO module
at all, it’s Class::InsideOut. And I can’t *wait* for Perl 5.10
to bring along Hash::Util::FieldHash.

If I were interested in something more comprehensive I’d use
Moose simply because it seems to be becoming the community
standard.

 Basically, it would be and OO implementation closer to how it's
 currently implemented in Java or C#, my hope is that it would
 make folks versed in those languages more comfortable with perl

Good luck with that.

I don’t mean to be down on you, but the fact is that no library
ever becomes the standard way of doing things in a language if
the base language provides “good enough” ways to do the same
thing by hand. You might reasonably argue about how good Perl 5
OO is, but it’s clearly not awful enough that you need a layer on
top of it to get anything done.

Moose has a singular advantage over other CPAN OO modules here
because it’s a backport of the Perl 6 OO system to Perl 5, is
extraordinarily comprehensive, and yet aims to coexist seamlessly
with non-Moose OO code. So its basic proposition is “use the
juicy bits of Perl 6 in your Perl 5 code, but only as much as you
like,” which puts it in a league above everyone else by virtue of
perception alone.

And still I don’t see Moose ever becoming “the no-brainer way of
doing OO in Perl 5.”

Now, I have no personal opinion on whether you should go forward
with your project or not. If you think it’s worth it, go for it.
Just don’t delude yourself about the extent of adoption you will
get. If your stuff is compelling, you will achieve some amount of
adoption and possibly a busy mailing list, just don’t expect it
to to become The Way To Do OO In Perl 5, much less rejuvenate
Perl in the eyes of Java/C# developers.

If the cold shower I’ve administered above hasn’t dissuaded or
discouraged you from pursuing your ideas, more power to you. :-)

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: RFC: String::Smart

2007-10-11 Thread Andy Armstrong

On 11 Oct 2007, at 11:46, A. Pagaltzis wrote:

* Andy Armstrong [EMAIL PROTECTED] [2007-10-10 22:45]:

Nice email address. :-P


It had to be done :)


This evening I started playing with String::Smart (the name is
as provisional as everything else).


Something with “language”, “type”, “quoting” or “escaping” would
be more appropriate I think.


Yup, OK.


In general a String::Smart string knows which transformations
are currently applied to a string and when you ask for a
particular representation of that string it computes the path
from the current encoding to the desired encoding and applies
the transformations in the appropriate order.


Have you seen Tom Moertel’s article on applying Haskell to this?
http://blog.moertel.com/articles/2006/10/18/a-type-based-solution- 
to-the-strings-problem


Oh that's nice! Thanks for that.


See also String::EscapeCage, which was discussed recently on this
list, and which is just as horribly named. :-)  It differs in
that it doesn’t address the chaining you mention, and by hooking
itself into tainting.


Yeah - it has slightly different aims as far as I can tell.


And I’m almost positive that I have seen one more module that
tries to address the exact same issue.


I assumed there must be one but couldn't find it. Anyone?

--
Andy Armstrong, Hexten





RFC: String::Smart

2007-10-11 Thread Andy Armstrong
Here's something I've been mulling for probably about eight years  
without doing anything about it.


Particularly in web applications - but in other areas too - people  
regularly make a complete mess of escaping / unescaping strings. At  
different times a string may need to be


* unescaped plain text
* SQL quoted
* entity encoded
* url encoded
* json encoded
* etc

It may even need to be encoded using some combination of those  
encodings - in which case the order in which they are applied to the  
string matters.


The continued popularity of XSS exploits, SQL injection bugs etc  
confirms that people still aren't getting it right. So it must be hard.


This evening I started playing with String::Smart (the name is as  
provisional as everything else). It lets you do


my $email = 'Andy Armstrong [EMAIL PROTECTED]';

my $enc = as html = $email;
print $enc\n;
# Prints Andy Armstrong lt;[EMAIL PROTECTED]gt

Multiple encodings may be applied:

# Apply HTML entity encoding and then query encoding
# Currently multiple encodings are separated by '_'
my $for_query = as html_query = $email;

You can also assert that a string is already escaped in some way -  
although I don't have a clean syntax for that. So you could say


my $this = is_already html = 'pA paragraph/p';
my $that = 'Just a string';

my $html_this = as html $this;
my $html_that = as html $that;

which would give you

$html_this = 'pA paragraph/p'; # No transformation - was already  
HTML

$html_that = 'lt;Just as stringgt;'; # Applied entity encoding

In general a String::Smart string knows which transformations are  
currently applied to a string and when you ask for a particular  
representation of that string it computes the path from the current  
encoding to the desired encoding and applies the transformations in  
the appropriate order.


So when you're generating a SQL query or a chunk of HTML you can just  
ask for the 'as sql' or 'as html' version of each string you use  
without worrying about how it's currently encoded.


Currently strings with a non-empty set of encodings turn into a  
blessed hashref that overloads stringification. I can't think of any  
other sensible way to associate the 'how is this currently encoded'  
metadata with a string. I'm open to suggestions.


What do people think? Useful?

http://imgs.xkcd.com/comics/exploits_of_a_mom.png

--
Andy Armstrong, Hexten





Re: relative.pm vs import.pm

2007-10-11 Thread Sébastien Aperghis-Tramoni
A. Pagaltzis wrote:

 * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-11 12:10]:
  But this will load *all* the modules below the current one,
  which is not the same thing as loading a set of selected
  modules. Imagine doing this with Plagger ;)

 Imagine trying to load all of Plagger's modules by hand. ;--)

Right, except I chose Plagger because this is typically a framework where
you only load a couple of modules from the gazillions available.

-- 
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.


Re: lambda - a shortcut for an apology

2007-10-11 Thread Ovid
--- Ovid [EMAIL PROTECTED] wrote:

 Well, if you want to use it in your own code and your work's code,
 that's fine (because I'm sure you find typing CONTROL-SHIFT-EL so
 much
 easier than sub {} :) but if it shows up in your CPAN modules, you
 might get a few complaints since this sugar, while a really nifty
 hack,
 adds nothing complex but does screw up older editors and will confuse
 the heck out of a lot of maintenance programmers.

You know, I was privately called on this and I was wrong.  Eric, I'm
sorry and I shouldn't have said this.  At this point on the CPAN, it
really doesn't matter what goes out there.  I really *do* like this
hack and who am I to say what namespace it should be in?

So my apologies for taking such a negative view.  I'm sorry if I gave
offense.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/


Re: lambda - a shortcut for an apology

2007-10-11 Thread David Precious
Ovid wrote:
 --- Ovid [EMAIL PROTECTED] wrote:
 
 Well, if you want to use it in your own code and your work's code,
 that's fine (because I'm sure you find typing CONTROL-SHIFT-EL so
 much
 easier than sub {} :) but if it shows up in your CPAN modules, you
 might get a few complaints since this sugar, while a really nifty
 hack,
 adds nothing complex but does screw up older editors and will confuse
 the heck out of a lot of maintenance programmers.
 
 You know, I was privately called on this and I was wrong.  Eric, I'm
 sorry and I shouldn't have said this.  At this point on the CPAN, it
 really doesn't matter what goes out there.  I really *do* like this
 hack and who am I to say what namespace it should be in?
 
 So my apologies for taking such a negative view.  I'm sorry if I gave
 offense.

For what it's worth, I don't think you were necessarily wrong or
excessively negative, you were offering your opinion.

It's definately a neat and clever hack, but I don't think I'd consider
using it in production code; adding a dependency on this module (and
the overhead of loading + parsing that module) for a relatively small
feature seems unreasonable to me.

The biggest reason of course is the surprise for a maintainance
programmer visiting that code later - if it's the first time they've
come across this module then causing them to scratch their heads whilst
thinking what on earth is *that*, and where's it coming from doesn't
strike me as a good idea.  (Which is the same reason I'll generally not
import any function, but prefer to call it explicitly like Foo::bar()
so that it's immediately obvious where to look to find it).

My own feeling is that the Acme namespace would have been appropriate as
this module does strike me as neat and fun, but not something I'd use
in production code.

But, as you said, who am I to say what namespace it should be in? :)

Cheers

Dave P

-- 
David Precious
http://blog.preshweb.co.uk/ :: http://www.preshweb.co.uk/


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Johan Vromans
Eric Wilhelm [EMAIL PROTECTED] writes:

Cute, but doesn't it break programs that already use non-ascii (e.g.,
Latin1)?

 How?

Because it's no different from the utf8 pragma:

  $ cat t.pl
  my $x = ë;
  $ perl -w t.pl
  $ perl -Mutf8 -w t.pl
  Malformed UTF-8 character (unexpected continuation byte 0x81, with no 
preceding start byte) ...
  Malformed UTF-8 character (1 byte, need 3, after start byte 0xeb) ...

(Note that the content of the string in t.pl is a single character
0xeb, which is Latin-1 for e-diaeresis.)

-- Johan


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Eric Wilhelm
# from Ovid
# on Thursday 11 October 2007 02:08:

but if it shows up in your CPAN modules, you
might get a few complaints since this sugar, 

Oh well ;-)  It's not an API element, just an internal dependency.  It 
works with perl 5.6.2 and 5.8.8.  Would anyone even notice?

If you're editing the file that uses it, you'll need a utf8-aware 
editor.

while a really nifty 
 hack, adds nothing complex but does screw up older editors and will
 confuse the heck out of a lot of maintenance programmers.

The great thing about maintenance programmers is that they come from the 
future (the one where utf8 just works.)

--Eric
-- 
To a database person, every nail looks like a thumb.
--Jamie Zawinski
---
http://scratchcomputing.com
---


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Eric Wilhelm
# from Johan Vromans
# on Thursday 11 October 2007 09:41:

 doesn't it break programs that already use non-ascii (e.g.,Latin1)?

 How?

Because it's no different from the utf8 pragma:

  $ cat t.pl
  my $x = ë;
  $ perl -w t.pl
  $ perl -Mutf8 -w t.pl
  Malformed UTF-8 character (unexpected continuation byte 0x81, with
 no preceding start byte) ...

OK,  Then it breaks them.  How would it not?  There's always 'no'.

--Eric
-- 
It is a mistake to allow any mechanical object to realize that you are 
in a hurry.
--Ralph's Observation
---
http://scratchcomputing.com
---


Re: CPAN security

2007-10-11 Thread Andy Armstrong

On 11 Oct 2007, at 18:23, Bill Moseley wrote:

In general, I prefer to run make and make test as a normal user and
then sudo make install, but sudo cpan sure is easy.  But, that's
hardly a complete test of code.


Grab the latest CPAN, set these two options:

   make_install_make_command [sudo make]
   mbuild_install_build_command [sudo ./Build]

Then chown your ~/.cpan to yourself (because if you've been doing  
sudo cpan some of the files will be owned by root)


$ sudo chown -R me:me ~/.cpan

and stop running CPAN as root. It'll then do make, make test, sudo  
make install or the ./Build equivalents.


That doesn't stop make install doing something hoopy as root of course.

--
Andy Armstrong, Hexten





Re: CPAN security

2007-10-11 Thread josh
On Thu, Oct 11, 2007 at 06:31:28PM +0100, Andy Armstrong wrote:
} On 11 Oct 2007, at 18:23, Bill Moseley wrote:
} In general, I prefer to run make and make test as a normal user and
} then sudo make install, but sudo cpan sure is easy.  But, that's
} hardly a complete test of code.
} 
} Grab the latest CPAN, set these two options:
} 
}make_install_make_command [sudo make]
}mbuild_install_build_command [sudo ./Build]
} 
} Then chown your ~/.cpan to yourself (because if you've been doing  
} sudo cpan some of the files will be owned by root)
} 
} $ sudo chown -R me:me ~/.cpan
} 
} and stop running CPAN as root. It'll then do make, make test, sudo  
} make install or the ./Build equivalents.
} 
} That doesn't stop make install doing something hoopy as root of course.

It is also easy to never implicate your /usr/bin/perl in anything. I'd
just prefer to quote myself at
http://mail.pm.org/pipermail/spug-list/2007-April/007823.html in
saying that it's an easier administration task to leave the OS perl
alone and have a separate /opt/blah/blah/blah perl for your real
work.

-- 
Josh


signature.asc
Description: Digital signature


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Eric Wilhelm
# from David Golden
# on Thursday 11 October 2007 11:25:

Uh, what about a vim shortcut that just does sub {.  E.g.:

And why do we have an 'eq' operator instead of 'equals' ?

IMO, shortcuts for typing long things will lead us to Eclipse.

--Eric
-- 
...our schools have been scientifically designed to
prevent overeducation from happening.
--William Troy Harris
---
http://scratchcomputing.com
---


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread David Golden
On 10/11/07, Ovid [EMAIL PROTECTED] wrote:
 Combined with that vim shortcut, this is just too cool :)

Uh, what about a vim shortcut that just does sub {.  E.g.:

imap ,{ sub {Space

Or even:

imap ,{ sub {SpaceSpace}LeftLeft

-- David


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread Ovid
--- Eric Wilhelm [EMAIL PROTECTED] wrote:

 And why do we have an 'eq' operator instead of 'equals' ?
 
 IMO, shortcuts for typing long things will lead us to Eclipse.

  lambda - a shortcut for sub {...}  

  my $code = #955; {...}; # instead of sub {...}

;)

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/


Re: lambda - a shortcut for sub {...}

2007-10-11 Thread A. Pagaltzis
* Eric Wilhelm [EMAIL PROTECTED] [2007-10-11 01:05]:
   http://search.cpan.org/~ewilhelm/lambda-v0.0.1/lib/lambda.pm

If I saw this in production code under my responsibility, I’d
submit it to DailyWTF. However, I have nothing against its use
in code I’ll never see. Carry on.

This opinion brought to you by Andy Lester’s Perlbuzz rant.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/