JOAP::Proxy::Package - Mixin for proxies that store metadata in the package
use JOAP::Proxy::Package; use base qw(JOAP::Proxy::Package JOAP::Proxy::Object);
This module provides a mixin class for storing JOAP::Proxy::Object metadata in the package of a class rather than in each instance. It also caches AUTOLOAD'd methods in the package namespace so they can be accessed by standard lookup the next time around.
First of all, this modules isn't really of use unless you're really messing around inside the JOAP proxy internals. If you aren't, well, just forget that you saw this package.
The module does two things:
This package should be the first in an @ISA or 'use base' statement, since it overloads some of the basic stuff in JOAP::Proxy. It is not a subclass of JOAP::Proxy -- this prevents the 'diamond problem', since Perl inheritance is depth-first.
If that doesn't make any sense, just remember: this package first.
The package defines the following four class methods for storing JOAP metadata:
This is for storing a reference to a hashtable of attribute descriptors. See JOAP::Proxy for how these work.
This is for storing a reference to a hashtable of method descriptors (again, fully documented in JOAP::Proxy).
A text description of the interface.
The most recent time the interface was checked with the server. It's a string in ISO 8601 format; see JOAP for a full description of that format.
The package also whomps ('overloads' is the wrong word, since it's not a subclass) the following methods in JOAP::Proxy:
For compatibility with the JOAP::Proxy interface, it's probably better to call the lowercase interface for application code, and reserve the uppercase interface for class declarations.
None by default.
JOAP also has information on contacting the author in case you think there's a bug.
This package uses Class::Data::Inheritable. You should look at that module's info if you're bent on messing around with it.
The package doesn't keep you from instantiating it directly, or from instantiating one of its immediate subclasses. You probably shouldn't, though.
It clouds up your namespace something awful. It should probably be reduced to a single Metadata object or something. But not right now.
The whole thing is kind of sneaky and underhanded.
The AUTOLOAD caching is kind of a problem for programs that use inheritance in their JOAP proxy classes. If class A is a superclass of class B, and they both have an attribute 'c', then calling:
...won't cache the accessor in package A. A later call to:
...will require a new AUTOLOAD, compile, and cache. Inefficient!
Worse, if the structure of attribute 'c' is changed for some reason in B (which is probably a bad idea), then calling:
...will cache A's version, and when you call:
...A's version will be called (by standard lookup), and will probably fail, or at least cause weird errors.
Evan Prodromou, <email@example.com>
Copyright (c) 2003, Evan Prodromou <firstname.lastname@example.org>.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA