Re: RFC: relative.pm

[A. Pagaltzis]

* Philippe Bruhat (BooK) [EMAIL PROTECTED] [2007-10-09 01:55]:
 What's wrong about this?
 
 eval use My::Big::Namespace::$_;
 for qw( This That Munger::Fast Munger::Precise );
 die $@ if $@;

That a) you check $@ to see if `eval` succeeded b) you do this
only once after performing multiple `eval`s. Correct:

eval use My::Big::Namespace::$_; 1 or die $@
for qw( This That Munger::Fast Munger::Precise );

In general, you should *always* (**ALWAYS**!!) check the success
of an eval block by checking its return value; if you caught an
exception you will get undef, so return something true (or at
least defined) as the last thing you do within the block. Then
you can check the block’s return value to see if it returned
something legitimate.

Checking $@ is unreliable for many reasons. __DIE__ handlers,
nested evals, objects in $@ etc all provide a myriad ways to eat
$@ before the `eval` returns or make the repeated evaluation of
$@ unsafe.

(I’ve half-joked before that someone should write Unbreak::Eval.)

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Sébastien Aperghis-Tramoni]

Eric Wilhelm wrote:


# from Sébastien Aperghis-Tramoni
# on Monday 08 October 2007 16:02:


 use relative;
 my $Customer = import relative qw(Report Customer);


This changes the require() on Foo::Report and Foo::Customer to run- 
time

though, right?


Right, but I'd say that for writing object-oriented code, there isn't  
such a need to do things at compile time, is it?



--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Ovid]

--- Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:

 Hmm.. As is, relative.pm already allows you to do that (thanks to Ken
 Williams' suggestion):
 
  package My::Enterprise::Framework;
  use relative;
  my $Customer = import relative qw(Report Customer);
  my $customer = $Customer-new($id);
 
 That is, import returns the full names of the successfully loaded  
 modules in list context, or the last one in scalar context. Is this  
 sufficient or did I misunderstand you?

Ah, I didn't notice that.  I think that would be fine.  The only caveat
being that this is lexically scoped, but I don't *think* there is
problem there.

Thanks for a nice module!

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: RFC: relative.pm

[Eric Wilhelm]

# from A. Pagaltzis
# on Monday 08 October 2007 22:44:

* Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 01:40]:
 The brackets are clunky though, particularly with the qw()
 inside them.

  use relative Third = -import = qw(with some args);

You mean `-import =` is less clunky than `[]`, and sometimes
having to write several `use relative` lines is less clunky than
being able to write only one? :-)

No.  I mean the brackets are clunky, particularly with the qw() inside 
them.

 And don't forget some way to not call import.

...
use relative Bar = [], Baz = [];

Doesn’t seem to be a problem… the mapping even is 1:1.

would be 1:1.

It's too bad the () isn't an option, so we have to struggle with [] vs 
[qw(...)] and whether or not to attempt parsing a list.  Maybe 
something involving '--', but then there's a quoting hassle again.  In 
all, the [qw(...)] is probably the easiest unless you want to read the 
source of caller()'s file and look for a () :-O.

Anyway, this is an unchecked eval, and always-on.

   # import the symbols from the loaded module into the caller module
   eval qq{ package $caller; $module-import };

--Eric
-- 
It works better if you plug it in!
--Sattinger's Law
---
http://scratchcomputing.com
---

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Ovid]

--- A. Pagaltzis [EMAIL PROTECTED] wrote:

 * Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 01:55]:
  This changes the require() on Foo::Report and Foo::Customer to
  run-time though, right?
 
 use Devel::BeginLift qw( require );

Cute trick, but I wondered if that would globally break require.

  #!/usr/bin/perl -l

  use strict;
  use warnings;

  use Devel::BeginLift qw(require);
  require Data::Dumper;
  BEGIN {
  no warnings 'once';
  print $Data::Dumper::Indent;
  }

Seems to have no impact on require at all.  I suspect that's because
it's not a subroutine.

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: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Jonathan Rockway]

Ovid wrote:
 I do get tired of writing code like that (it happens a lot in test
 suites when I have use_ok $CLASS in a BEGIN block).
   


OT, but 'ok.pm' is quite nice:

   use Test::More tests = 1;
   use ok 'My::Module'; # test runs at compile time

Regards,
Jonathan Rockway




signature.asc
Description: OpenPGP digital signature

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Eric Wilhelm]

# from A. Pagaltzis
# on Monday 08 October 2007 22:50:

* Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 01:55]:
 This changes the require() on Foo::Report and Foo::Customer to
 run-time though, right?

    use Devel::BeginLift qw( require );

The import() method is calling require at run-time.  That's going to 
take some heavy lifting ;-)

--Eric
-- 
Consumers want choice, consumers want openness.
--Rob Glaser
---
http://scratchcomputing.com
---

(OT) Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Ovid]

--- Jonathan Rockway [EMAIL PROTECTED] wrote:

 OT, but 'ok.pm' is quite nice:
 
use Test::More tests = 1;
use ok 'My::Module'; # test runs at compile time

Oh, I really like that, but it still causes an issue for me.  You see,
a lot of what I do is stuff like this:

  my $CLASS;
  BEGIN {
  $CLASS = 'Customer';
  use_ok $CLASS or die;
  }

  can_ok $CLASS, 'new';
  ok my $cust = $CLASS-new, '... and we can call it';
  isa_ok $cust, $CLASS, '... and the object it returns';

This means that if I need to refactor classes to better namespaces, I
merely change the $CLASS = line.  With the lovely ok.pm module, I
still have the following clunky construct:

  my $CLASS;
  BEGIN {
  $CLASS = 'Customer';
  }
  use ok $CLASS or die;

  can_ok $CLASS, 'new';
  ok my $cust = $CLASS-new, '... and we can call it';
  isa_ok $cust, $CLASS, '... and the object it returns';

Those BEGIN blocks really annoy the hell out of me at times :(

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: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Eric Wilhelm]

# from Sébastien Aperghis-Tramoni
# on Tuesday 09 October 2007 00:07:

 This changes the require() on Foo::Report and Foo::Customer to run-
 time though, right?

Right, but I'd say that for writing object-oriented code, there isn't
   such a need to do things at compile time, is it?

Probably not, but they're still different, and thus could lead to 
head-scratching.

If the shorthand feature just installed a subroutine (what aliased 
does), there would be no difference.

  use relative 'Foo';
  Foo-new;

is:

  BEGIN {
require relative;
relative-import('Foo');
  }
  Foo-new;

Where the scalar usage is like:

  BEGIN {
require relative;
  }
  my $Foo = relative-import('Foo');
  $Foo-new;

You can use scalars in this way (via $_[2] = 'Bar::Foo'), but they have 
to be declared before the use line.

  my $Foo;
  use relative Foo = $Foo;
  $Foo-new;

So, I'm inclined to think that the sub is the way to go, though it would 
be nice if they went away at runtime (in order to not be accidental 
methods.)  5.10 and $^H anyone?

--Eric
-- 
Time flies like an arrow, but fruit flies like a banana.
--Groucho Marx
---
http://scratchcomputing.com
---

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[A. Pagaltzis]

* Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 09:50]:
 The import() method is calling require at run-time.  That's
 going to take some heavy lifting ;-)

Err, I meant `qw( import )`.

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

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[A. Pagaltzis]

* Ovid [EMAIL PROTECTED] [2007-10-09 09:40]:
 --- A. Pagaltzis [EMAIL PROTECTED] wrote:
  * Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 01:55]:
   This changes the require() on Foo::Report and Foo::Customer
   to run-time though, right?
  
  use Devel::BeginLift qw( require );
 
 Cute trick, but I wondered if that would globally break
 require.

Wrong trick, I meant to begin-lift `import`, not `require`, ugh.

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

RE: RFC: relative.pm

[Pearce, Martyn]

-Original Message-
From: Jonathan Rockway [mailto:[EMAIL PROTECTED] 

Pearce, Martyn wrote:
 It is?  How so? 
   

Don't top-post.  It ruins the flow for people trying to reply to you.

Fair point, apologies.  I blame outlook, which I use only under protest.

To answer your question, see 
http://use.perl.org/~Aristotle/journal/33995 .

FWIW, I (and thousands upon thousands of others) have used FindBin for
years without problems.  However, it is annoying if you run 
into an edge
case that doesn't work.  I never have though.  In fact, I've 
even gotten
away with things like 'use lib  $Bin/../lib' working across 
platforms :)

Me too.  Having read the note, I see completely broken means has a
weird edge case that may not work right in certain not-so-common
environments, but works great 95% of the time.

That it has a bug is a useful, if not entirely surprising relevation (it
is, after all, software).
But the statement made in the journal, that FindBin is utterly broken,
seems to be crying wolf.

Mx.

Re: (OT) Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Smylers]

Ovid writes:

 With the lovely ok.pm module, I still have the following clunky
 construct:
 
   my $CLASS;
   BEGIN {
   $CLASS = 'Customer';
   }
   use ok $CLASS or die;
 
   can_ok $CLASS, 'new';
   ok my $cust = $CLASS-new, '... and we can call it';
   isa_ok $cust, $CLASS, '... and the object it returns';
 
 Those BEGIN blocks really annoy the hell out of me at times :(

Well don't have them then -- put the assignment in the use statement,
which is run at BEGIN time anyway:

  use Test::More tests = 1;
  my $CLASS;
  use ok $CLASS = 'DateTime';

Smylers

Re: (OT) Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[A. Pagaltzis]

* Smylers [EMAIL PROTECTED] [2007-10-09 10:25]:
 Well don't have them then -- put the assignment in the use
 statement, which is run at BEGIN time anyway:
 
   use Test::More tests = 1;
   my $CLASS;
   use ok $CLASS = 'DateTime';

Sneaky! I like.
-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle

Re: RFC: relative.pm

[Sébastien Aperghis-Tramoni]

Eric Wilhelm wrote:

 Anyway, this is an unchecked eval, and always-on.

# import the symbols from the loaded module into the caller module
eval qq{ package $caller; $module-import };

Indeed. Thanks for spotting this.

-- 
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)

[Sébastien Aperghis-Tramoni]

Ovid wrote:

 --- Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:

  Eric Wilhelm wrote:
use relative;
my $Customer = import relative qw(Report Customer);
  
   This changes the require() on Foo::Report and Foo::Customer to run-
   time though, right?
 
  Right, but I'd say that for writing object-oriented code, there isn't
  such a need to do things at compile time, is it?

 You know, I hadn't considered the runtime/compile-time issue when I
 first saw this.  Eric's right that this does change the semantics.  I
 suppose one could wrap it in a BEGIN block, but that makes it worse:

   use relative;
   my ( $Report, $Customer );
   BEGIN {
   ( $Report, $Customer ) = import relative qw(Report Customer);
   }

 I do get tired of writing code like that (it happens a lot in test
 suites when I have use_ok $CLASS in a BEGIN block).

 I do agree that with OO modules that compile-time should be less of an
 issue, but it's not universally the case.  Still, I think the import
 relative is probably enough for me.

To be honest, I'm not really convinced because I don't see why so much
things should happen at compile-time, but I'll add the -aliased option
in the next release.


-- 
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: RFC: relative.pm

[Jonathan Rockway]

Pearce, Martyn wrote:
 -Original Message-
 From: Jonathan Rockway [mailto:[EMAIL PROTECTED] 

 Pearce, Martyn wrote:
 
 It is?  How so? 
   
 Don't top-post.  It ruins the flow for people trying to reply to you.
 

 Fair point, apologies.  I blame outlook, which I use only under protest.
   

Ah, understood.  I was stuck with Outlook at my last job, and it was
impossible to get it to quote a message in a way that you could actually
reply to things point by point.  It seemed optimized for sending a
message to every person in the company and making all of your text
blue.  What a fucking joke.

Regards,
Jonathan Rockway



signature.asc
Description: OpenPGP digital signature

Re: RFC: relative.pm

[Andy Armstrong]

On 9 Oct 2007, at 11:05, Jonathan Rockway wrote:

What a fucking joke.


If it's a joke you should use Comic Sans so everyone /knows/ it's funny.

--
Andy Armstrong, Hexten

Re: RFC: relative.pm

[Jonathan Rockway]

Andy Armstrong wrote:
 On 9 Oct 2007, at 11:05, Jonathan Rockway wrote:
 What a fucking joke.

 If it's a joke you should use Comic Sans so everyone /knows/ it's funny.



No no, Comic Sans is for presentations to the shareholders!

Regards,
Jonathan Rockway




signature.asc
Description: OpenPGP digital signature

Re: RFC: relative.pm

[Adrian Howard]

On 9 Oct 2007, at 11:19, Jonathan Rockway wrote:


Andy Armstrong wrote:

On 9 Oct 2007, at 11:05, Jonathan Rockway wrote:

What a fucking joke.


If it's a joke you should use Comic Sans so everyone /knows/ it's  
funny.


No no, Comic Sans is for presentations to the shareholders!


Somebody who is presenting to shareholders knows how to change the  
default font?


Weird...

Adrian

Re: use ok / use or_die

[Eric Wilhelm]

# from Ovid
# on Tuesday 09 October 2007 01:47:

Though smylers just thought of 'or_die' (we work in the same office):

  use Test::More 'no_plan';
  use constant CLASS = 'My::Customer';
  use     or_die CLASS;
  require or_die CLASS;

That would be a strange package name for a testing module, but hey ...

I'm not sure about the name either.  Maybe just parameters to import() ?

  use ok or_die = 'My::Customer';

In general, why bother making .pm files for them?  Just patch Test::More 
ala:

  $INC{'ok.pm'} = 1;
  sub ok::import { ... }

  $INC{'or_die.pm'} = 1;
  sub or_die::import { ... }

  $INC{'or_bail.pm'} = 1;
  sub or_bail::import { ... }

Given that none of them are valid until Test::More is loaded, seems 
reasonable.  (Also saves declaring a test_requires item.)

--Eric
-- 
...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments.
--Neal Stephenson
---
http://scratchcomputing.com
---