Re: relative.pm vs import.pm
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: relative.pm vs import.pm
* 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: relative.pm vs import.pm
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.
relative.pm vs import.pm
Did anyone mention import.pm in these threads? http://search.cpan.org/~mikeking/import-1_01/import.pod --Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --- http://scratchcomputing.com ---
Re: RFC: relative.pm
* 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: RFC: relative.pm
# 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: RFC: relative.pm
-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: RFC: relative.pm
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: RFC: relative.pm
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
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
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
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: RFC: relative.pm
* Bill Ward [EMAIL PROTECTED] [2007-10-07 04:55]: Would lib::relative be too weird? There is already a `lib` pragma; `lib::relative` to me sounds like “does something like `lib`, only relatively,” which more naturally suggests something to do with relative paths and [EMAIL PROTECTED] I proposed pkg::relative which Eric Wilhelm liked; no word from Sébastien yet though. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: RFC: relative.pm
On Mon, Oct 08, 2007 at 01:51:21PM +0200, A. Pagaltzis wrote: There is already a `lib` pragma; `lib::relative` to me sounds like ???does something like `lib`, only relatively,??? which more naturally suggests something to do with relative paths and [EMAIL PROTECTED] I proposed pkg::relative which Eric Wilhelm liked; no word from Sébastien yet though. I don't recall seeing any mumbling on p5p about this. That would probably be a good idea, as lower-case module names are traditionally reserved for the core. It would be an especially good idea if you're going to mess around under some pre-existing pragma's namespace like lib::anything would. -- David Cantrell | Godless Liberal Elitist All children should be aptitude-tested at an early age and, if their main or only aptitude is for marketing, drowned.
Re: RFC: relative.pm
A. Pagaltzis wrote: * Bill Ward [EMAIL PROTECTED] [2007-10-07 04:55]: Would lib::relative be too weird? There is already a `lib` pragma; `lib::relative` to me sounds like does something like `lib`, only relatively, which more naturally suggests something to do with relative paths and [EMAIL PROTECTED] I proposed pkg::relative which Eric Wilhelm liked; no word from Sébastien yet though. Sorry, I forgot to answer this mail. AIUI, lib::relative already exists: it's called FindBin (and the derivates). pkg::relative would seem like an incorrect name because it carries a semantic you can't achieve: in Perl, you don't load packages but modules, which happen to define (or not) a package of the same name. So, IMO, there's no other semantic to differentiate from when used as a Cuse argument, hence the plain relative name. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Pearce, Martyn wrote: It is? How so? Don't top-post. It ruins the flow for people trying to reply to you. 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 :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: RFC: relative.pm
# from Sébastien Aperghis-Tramoni # on Monday 08 October 2007 15:27: Since the beginning, I had though that if I wanted to pass arguments to the modules, I'd write it like this: use relative qw(First Second), Third = [qw(with some args)] because I usually load modules without passing them any arguments. And don't forget some way to not call import. The brackets are clunky though, particularly with the qw() inside them. use relative Third = -import = qw(with some args); And maybe use relative Third = -import = []; --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown --- http://scratchcomputing.com ---
Re: RFC: relative.pm
* 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? :-) And don't forget some way to not call import. use Foo::Bar; use Foo::Baz; # == use relative qw( Bar Baz ); use Foo::Bar qw( quux ); use Foo::Baz qw( qux ); # == use relative Bar = [ 'quux' ], Baz = [ 'qux' ]; use Foo::Bar qw(); use Foo::Baz qw(); # == use relative Bar = [], Baz = []; Doesn’t seem to be a problem… the mapping even is 1:1. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: relative.pm
On Sun, Oct 07, 2007 at 12:40:06AM +0200, S?bastien Aperghis-Tramoni wrote: Dr.Ruud wrote: S?bastien Aperghis-Tramoni schreef: package BigApp::Report; These would also be nice: package BigApp::__FROMFILE__; package BigApp::__FROMFILE__($RCSfile); Not sure how this is supposed to work, but I think this is beyond the aim of relative.pm A source filter, perhaps? But yes, IMHO it is beside the point too. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. pgpvFtDdyX1TY.pgp Description: PGP signature
Re: relative.pm
On 7 Oct 2007, at 15:33, Peter Pentchev wrote: A source filter, perhaps? Run away! :) -- Andy Armstrong, Hexten
Re: RFC: relative.pm
On Oct 6, 2007, at 1:27 PM, Sébastien Aperghis-Tramoni wrote: Paul Hoffman wrote: use relative to = Enterprise::Framework = qw(Base Factory); # loads Enterprise::Framework:Base, Enterprise::Framework::Factory Hmm, the last example is equivalent to this: use relative qw(to Enterprise::Framework Base Factory); Which might conceivably cause a problem for someone at some point. You might consider requiring the string ':to' instead of 'to'. I agree that this syntax prevents from loading a module named to.pm, but I think this is a good trade-off given than adding any other character will require quoting the word, and I'd like to keep the syntax as simple as possible. An acceptable compromise it to write it as C -to = Root As a side note, using find(1) on a mini-CPAN and Google CodeSearch, I only found 3 modules named tp.pm : - CGI::FormMagick::L10N::to (in MITEL/CGI-FormMagick-0.89.tar.gz) - DateTime::Locale::to (in DROLSKY/DateTime-Locale-0.35.tar.gz) - Number::Tolerant::Type::to (in RJBS/Number-Tolerant-1.550.tar.gz) If you really wanted a ::to you could just rearrange the order and say: use relative qw(Enterprise::Framework Base Factory to); The only thing it couldn't support is a single pkg called ::to. Chris
Re: RFC: relative.pm
A. Pagaltzis wrote: even with the current interface, it’s possible to load a to.pm if you do it this way: use relative to = __PACKAGE __, qw(to from before after boo); But that’s a) noisy b) less than self-suggesting. My I suggest this: use relative to = self, qw(foo bar roo); Anything else would be used the way it is currently defined. I like relative to = 'self', because it seems a bit more regular, and somewhat self documenting.
Re: RFC: relative.pm
On 7 Oct 2007, at 21:48, Jim Schneider wrote: use relative to = self, qw(foo bar roo); Anything else would be used the way it is currently defined. I like relative to = 'self', because it seems a bit more regular, and somewhat self documenting. I think that's the default. You only use 'to' (or -to now :) to resolve names relative to some other namespace. This module allows you to load modules using only parts of their name, relatively to the current module or to a given module. Module names are by default searched below the current module, but can be searched upper in the hierarchy using the ..:: syntax. From: http://search.cpan.org/~saper/relative-0.02/lib/relative.pm -- Andy Armstrong, Hexten
Re: RFC: relative.pm
Hello Aristotle, A. Pagaltzis wrote: Hi Sébastien, * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 03:05]: package BigApp::Report; use relative to_parent = qw(Utils); # loads BigApp::Utils use relative to_self = qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish I like the idea. Catalyst privately invents something like that, so obviously there are other people who feel the same need. Yes, POE also provide a similar mechanism, that's why I was thinking to provide a generic module to do that. But I like neither the name nor the interface. How about this: package BigApp::Report; use subclass qw(..::Utils Create Publish); # loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish subclass would imply more OO semantic than I'd like, as the module just loads others modules, but I agree it's a better name than relative and I can't find a better one. Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. Thanks -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
On 6 Oct 2007, at 11:17, Sébastien Aperghis-Tramoni wrote: I like the idea. Catalyst privately invents something like that, so obviously there are other people who feel the same need. Yes, POE also provide a similar mechanism, that's why I was thinking to provide a generic module to do that. But I like neither the name nor the interface. How about this: package BigApp::Report; use subclass qw(..::Utils Create Publish); # loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish subclass would imply more OO semantic than I'd like, as the module just loads others modules, but I agree it's a better name than relative and I can't find a better one. Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); ? -- Andy Armstrong, Hexten
Re: RFC: relative.pm
Andy Armstrong wrote: But I like neither the name nor the interface. How about this: package BigApp::Report; use subclass qw(..::Utils Create Publish); # loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish subclass would imply more OO semantic than I'd like, as the module just loads others modules, but I agree it's a better name than relative and I can't find a better one. Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
On 6 Oct 2007, at 11:46, Sébastien Aperghis-Tramoni wrote: Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. I always hesitate to suggest Aristotle is mistaken - it's not a common occurrence - but I really think 'subclass' is wrong. As you said this is an extension to the semantics of use that has (I presume) nothing to do with any inheritance relationship the modules may have with each other. I quite like 'relative' to be honest. And I like the idea of the module. I'll use it immediately when you release it, thanks. -- Andy Armstrong, Hexten
Re: RFC: relative.pm
Andy Armstrong wrote: Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. I always hesitate to suggest Aristotle is mistaken - it's not a common occurrence - but I really think 'subclass' is wrong. As you said this is an extension to the semantics of use that has (I presume) nothing to do with any inheritance relationship the modules may have with each other. Mixing both your and Aristotle's suggestions, here is the new synopsis: package BigApp::Report; use relative qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish use relative qw(..::Utils); # loads BigApp::Utils use relative to = Enterprise::Framework = qw(Base Factory); # loads Enterprise::Framework:Base, Enterprise::Framework::Factory I quite like 'relative' to be honest. And I like the idea of the module. I'll use it immediately when you release it, thanks. Heh, thanks. I'll announce here when the module is available. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
On 10/6/07, Andy Armstrong [EMAIL PROTECTED] wrote: I always hesitate to suggest Aristotle is mistaken - it's not a common occurrence - but I really think 'subclass' is wrong. As you said this is an extension to the semantics of use that has (I presume) nothing to do with any inheritance relationship the modules may have with each other. ++ I quite like 'relative' to be honest. And I like the idea of the module. I'll use it immediately when you release it, thanks. I agree with relative vs subclass -- and it does seem to be a very useful module for anything with many classes and subclasses. David
Re: relative.pm
Sébastien Aperghis-Tramoni schreef: package BigApp::Report; These would also be nice: package BigApp::__FROMFILE__; package BigApp::__FROMFILE__($RCSfile); -- Affijn, Ruud Gewoon is een tijger.
Re: RFC: relative.pm
On Oct 5, 2007, at 9:04 PM, Sébastien Aperghis-Tramoni wrote: The interest of such a module would be to ease writing modules using a big set of sibling modules (in the same hierarchy), and would also simplify refactoring and renaming. As of now the user still has to write the whole package later in the code: package BigApp::Report; use relative to_self = qw(Create Publish); my $p = BigApp::Report::Publish-new; If there were a return value from import(), they could do something like this instead: package BigApp::Report; use relative; my $Pub = import relative to_self = qw(Create Publish); my $p = $Pub-new; -Ken
Re: RFC: relative.pm
* Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 20:30]: As a side note, using find(1) on a mini-CPAN and Google CodeSearch, I only found 3 modules named tp.pm: Don’t forget the darkPAN though. An acceptable compromise it to write it as C -to = Root That’s what I’d suggest. FWIW, even with the current interface, it’s possible to load a to.pm if you do it this way: use relative to = __PACKAGE __, qw(to from before after boo); But that’s a) noisy b) less than self-suggesting. I’d stick the hyphen on there to avoid that sort of irregularity. It’s a really tiny change anyway. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: RFC: relative.pm
# from A. Pagaltzis # on Saturday 06 October 2007 13:44: Then again, I’d called mine lib::relative. Maybe this one should be pkg::relative? That sounds good. --Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --- http://scratchcomputing.com ---
Re: RFC: relative.pm
Ken Williams wrote: If there were a return value from import(), they could do something like this instead: package BigApp::Report; use relative; my $Pub = import relative to_self = qw(Create Publish); my $p = $Pub-new; Except that, 1), the API has changed a bit, 2) I think import should return a list in this case because it's importing several modules at once. So would write it like this: package BigApp::Report; use relative; my ($Create, $Publish) = import qw(Create Publish); my publisher = $Publish-new; Looks a good idea. It should also DTRT so my $Publish = import qw(Publish); works as one expects. The only case left is: my $What = import qw(One Two Three); It could return the last one in order to mimic the comma operator. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
David Cantrell wrote: Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. '..' is only meaningful in the Unix/Win32 world. VMS, RISC OS and others call it something else. On the other hand, I think it's safe to assume that anyone using those platforms and perl will know what .. means and if they don't I'm sure you'll document it. For best or worse, Unix semantics are pretty common and have contaminated many other things not related to filesystems. Think of URL or XPath[1] for example. [1] http://www.w3.org/TR/xpath#path-abbrev -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
A. Pagaltzis wrote: * Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 20:30]: As a side note, using find(1) on a mini-CPAN and Google CodeSearch, I only found 3 modules named tp.pm: Don’t forget the darkPAN though. On a side note, if some people here know Perl modules outside CPAN but available on the internet, I'll gladly accept patches to list them in Module::ThirdParty. An acceptable compromise it to write it as C -to = Root That’s what I’d suggest. FWIW, even with the current interface, it’s possible to load a to.pm if you do it this way: use relative to = __PACKAGE __, qw(to from before after boo); But that’s a) noisy b) less than self-suggesting. I’d stick the hyphen on there to avoid that sort of irregularity. It’s a really tiny change anyway. Ok, ok, you've convinced me :-) Will change this, along with your patch and Ken's idea. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: relative.pm
Dr.Ruud wrote: Sébastien Aperghis-Tramoni schreef: package BigApp::Report; These would also be nice: package BigApp::__FROMFILE__; package BigApp::__FROMFILE__($RCSfile); Not sure how this is supposed to work, but I think this is beyond the aim of relative.pm -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
On 10/6/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 6 Oct 2007, at 11:46, Sébastien Aperghis-Tramoni wrote: Would it also do use relative [to = 'My::Big::Namespace'] = qw( This That Munger::Fast Munger::Precise ); It can easily do that. The problem is more the name. In this case, use relative to ... works well. But in y original example, use subclass works better. Maybe I should provide both modules then. I always hesitate to suggest Aristotle is mistaken - it's not a common occurrence - but I really think 'subclass' is wrong. As you said this is an extension to the semantics of use that has (I presume) nothing to do with any inheritance relationship the modules may have with each other. I quite agree. I quite like 'relative' to be honest. And I like the idea of the module. I'll use it immediately when you release it, thanks. I think the word relative is correct but lacks context. The only good thing about subclass is that it gives context, but the OO implications are too strong. Maybe some other name that suggests *what* is relative? Would lib::relative be too weird?
Re: RFC: relative.pm
On 10/6/07, David Cantrell [EMAIL PROTECTED] wrote: Sébastien Aperghis-Tramoni wrote: Also agreeing for the API change. I know I was pondering about using .. but can't remember why I didn't. '..' is only meaningful in the Unix/Win32 world. VMS, RISC OS and others call it something else. On the other hand, I think it's safe to assume that anyone using those platforms and perl will know what .. means and if they don't I'm sure you'll document it. Mac OS X also uses '..' since it's Unix-based. That covers the vast majority of Perl platforms.
RFC: relative.pm
Hello, Following a suggestion by a coworker, I wrote the following module: NAME relative - Load modules with relative names DESCRIPTION This module allows you to load modules using only parts of their name, relatively to the caller module. SYNOPSIS package BigApp::Report; use relative to_parent = qw(Utils); # loads BigApp::Utils use relative to_self = qw(Create Publish); # loads BigApp::Report::Create, BigApp::Report::Publish __END__ The interest of such a module would be to ease writing modules using a big set of sibling modules (in the same hierarchy), and would also simplify refactoring and renaming. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: RFC: relative.pm
Hi Sébastien,
* Sébastien Aperghis-Tramoni [EMAIL PROTECTED] [2007-10-06 03:05]:
package BigApp::Report;
use relative to_parent = qw(Utils);
# loads BigApp::Utils
use relative to_self = qw(Create Publish);
# loads BigApp::Report::Create, BigApp::Report::Publish
I like the idea. Catalyst privately invents something like that,
so obviously there are other people who feel the same need. But I
like neither the name nor the interface. How about this:
package BigApp::Report;
use subclass qw(..::Utils Create Publish);
# loads BigApp::Utils, BigApp::Report::Create, BigApp::Report::Publish
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle
