This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Undocumented feature of File::Find?
Newsgroups: comp.lang.perl.modules
Date: Wed, 12 Nov 2003 23:33:00 GMT
Organization: Comcast Online
>>>>> "MO" == Miko O'Sullivan <miko@idocs.com> writes:
MO> I don't even see this behavior documented in the documentation you
MO> quote. Yes, it says that you can pass a hash reference to find. It
MO> *doesn't* say that that same hash ref will be passed to wanted() in
MO> the @_ array. In fact, some versions of the File::Find docs
MO> explicitly say that *no* arguments are passed to wanted:
in looking at the source i found that the callback func is always called
like this:
{ &$wanted_callback }; # protect against wild "next"
the & style of the call means that the existing @_ that find() sees is
passed along to the callback function. you are seeing this behavior but
it is not documented. so i would not rely upon it nor use any arguments
to the wanted function.
MO> The wanted() function does whatever verifications you
MO> want on each file and directory. It takes no arguments
MO> but rather does its work through a collection of
MO> variables.
the docs in 5.6.1 don't mention the lack of arguments to wanted. but i
agree that you should assume none.
MO> So... no, I still see nothing in the docs that indicates that the
MO> hash ref is passed as an argument to wanted().
all the args are passes due to the & style call. if you look at the
code, the find sub has this line:
_find_opt(wrap_wanted($wanted), @_);
and _find_opt has this:
my $wanted = shift;
which means @_ will be the same as what was seen by find().
MO> Perhaps the docs need a little clarification? Like every other art
MO> form, most technical documents can always stand a little tweaking.
MO> :-)
no, the docs are correct to state that wanted gets no args which means
you shouldn't assume any args. the fact that the code does pass args it
is not of concern to you. they could easily change all the callbacks to:
{ $wanted_callback->() };
and you won't see any args. but the module will work just the same. i
think the & style call is a speed optimization here as it doesn't have
to setup the stack for args. and i would lean towards the speedup over
forcing no args to wanted. so do not use those args or your code could
break in some future version of the module.
and if you need those args, just keep a lexical copy of the hash ref
around that is visible to wanted. simple.
===