Having written a "do everything" object like this myself (WebPerl::JSObject), I can confirm that there are some methods you won't be able to override, and some you probably shouldn't (e.g. those from UNIVERSAL). IMHO, you probably should just bite the bullet and document for your users that not all method calls will be AUTOLOADed. Either that, or reconsider using AUTOLOAD in the first place - for example, I wrote IPC::Run3::Shell because the AUTOLOADing behavior of Shell is a bit too dangerous, or I wrote Util::H2O to provide protection against typos when accessing hashes. OTOH, for a dynamic object, a purely hashref- and arrayref-based interface might make sense from a user's point of view.
However, methods like FETCH and FIRSTKEY shouldn't be a problem (WebPerl example, requires a modern browser). You haven't shown us an SSCCE, but I suspect that perhaps you're using a single class to handle the AUTOLOAD and the tied interfaces as well, which I would recommend against; you should use separate classes for each of the tied types.
Also, a word of warning: it's possible to make an interface "too clever" such that it gets so complex that only the author will understand it ("It's so simple! Just press Ctrl+Shift+\ while clicking the middle mouse button!"). Consider as one counterexample the method-based API of Hash::Ordered, which some would consider that a quite clean API. Of course an API like the one you are designing could be made quite clean as well if you don't overload it too much, I don't know since you haven't described the whole thing, but it is something to keep in mind.
Minor edits.
In reply to Re: AUTOLOAD vs. DESTROY...
by haukex
in thread AUTOLOAD vs. DESTROY...
by coreybrenner
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |