On 1/24/07, Glenn Linderman <[EMAIL PROTECTED]> wrote:
Steffen, you mention "the array implementation" and replacing it with a
"hash-based" implementation. Is the root problem, then, some O(n^2)
algorithm for lookups by name searching through "the array
implementation" to find the name? Or what?
A::Z maintains a strict OO structure. The object you work with is an
A::Z::Archive object, and it keeps an array of A::Z::Member objects
that represent individual files in the array (and maintain all their
state). In order to get a list of the filenames, one has to iterate
over the array of member objects and call their accessor to retrieve
the filename.
Rather than store an array of member objects, Steffan was suggesting
that A::Z::Archive keep a hash of member objects, keyed off the
filename. That makes it easy to either get a list of all names or to
find individual files.
I don't understand where "this bites if somebody does a
$member->fileName("NewName").", nor why. A little more verbose
explanation of the problem might result in more ideas being generated.
The way to rename a file in the archive is to call fileName as an
accessor on the A::Z::Member object. But the A::Z::Member object has
no way to update the hash in A::Z::Archive so that hash will have the
old filename pointing to the A::Z::Member object with a new filename
internally. The only way to avoid this is to make renaming happen as
a method call on A::Z::Archive, but this starts to break down the
entire OO model even further. (It could be done, but it's a much
bigger effort.)
And David mentions caching internally... but only for readonly use... my
point, perhaps already thought of and discarded for some valid reason,
is that perhaps it would be possible for A::Z to do the caching
internally, but support updates to the cache for modification
operations? Caches don't necessarily need to be read-only, they can be
updatable... if there is a central place where the "array" data
structure is maintained, could not that code be modified to also update
the (internal) cache, to allow higher performance interfaces?
From my previous description hopefully it's clear what the problem is.
Perhaps if A::Z::Member had a back-reference to the containing
A::Z::Archive, calls to rename could update the cache. But then
you've got to have DESTROY break the circular references and so on.
It's all "fixable", it's just not a quick fix, whereas caching names
in PAR.pm and _first_member is.
David
