Re^7: XML::Twig Support for Parameter Entities (AAaD)

[tye]

Yes, I realize that 'require' not reparsing the file is a 'feature'. Was that supposed to help justify why you want to use 'require' to get back values instead of using 'do'? If so, I didn't understand it.

Using a tool that can easily not give you back the value that you want to get back because of something that could have been done in code quite distant from the code at hand is not what I would call a 'feature'.

[shmem]

Loading a datastructure from a file not related to @INC once, 'do' and 'require' amount to the same. For a conditional 'do', I could check %INC instead of using 'require' and checking the return value, so you have a point here. For autoloading anonsubs as really private subs into a package, things are different, since 'require' checks @INC.

Yes, it is a bit sad that require doesn't return the same value from the first call at subsequent calls. For the above case, the AUTOLOAD block has to handle that via a private hash.

[tye]

My testing shows that 'do' makes use of @INC.

So it seems that I've found two problems with do's bit:

except that it's more efficient and concise, keeps track of the current filename for error messages, searches the @INC directories, and updates %INC if the file is found.

For me, 'do' does "search @INC" and does "update %INC", despite the docs.

[shmem]

For me, 'do' does "search @INC" and does "update %INC", despite the docs.

No, not despite, exactly as the docs state: do searches @INC - I have gotten this bit wrong (you apparently too just now).

So, the only remaining difference between require and do is that require doesn't load a file present in %INC, while do loads unconditionally. But since require doesn't cache the value it returns at the first call, I have to cache it anyways.

Which means, that I'll be using do furthermore for all the cases I presented. Thanks!

update: IMO perl should have an internal table holding the return values from require evals.