Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 9 Sep 2003, Gordon Henriksen wrote:
>
> > Random thought....
> >
> > There's some discussion on perl-qa right now about how Test::More
> > should implement "is_deeply", which executes a code block and tests
> > that the return value is equivalent to a particular nested data
> > structure. (The question posed on that list is with regard to how to
> > handle tie()'d objects, which is not what I'm addressing here.)
> > Result of that discussion's outcome, should the serialization API
> > being discussed here enable the following behavior?
> >
> > ok(freeze($expected) eq freeze($actual));
> >
> > I bring this up because using object addresses as IDs in the
> > serialization entirely prevents this usage.
>
> Good. Having waded through one of the threads on p5p just a minute
> ago, I'm not willing to guarantee this. In fact, I'm willing to
> explicitly not guarantee this. If we want to compare two frozen
> structures, string equality is *not* the way to go.
>
> Each freeze could, theoretically, choose a different freezing method
> yet still represent the original.
What do you mean by a "different freezing method?" That key-value pairs
from two externally identical hashes could be frozen in different
orders? I can see that. Sorting large hashes can be expensive, and
certainly requires memory allocation.
Or do you mean that freeze($objA) and freeze($objB)--freezing
(definitionally identical!) object graphs and with no intervening code
between the two calls to freeze--could internally and arbitrarily select
a significantly divergent object graph encoding? I can't see that at
ALL...
Over time (and revisions), I certainly can see a desire not to marry
parrot-freeze to a specific binary representation. That's not the
question I intended to raise--I asked a question only of repeatability,
not of permanent format invariance.
> This is a Good Place for a black-box comparison op, which string
> equality definitely is not.
(At which point do extremely complex routines cease to be operators?)
A black-box comparison of the (live) object graphs, or black-box
comparison of the serializations themselves?
I can see the former--while it's precisely the problem that consistent
traversal outputs avoids, a "deep ==" could have utility and avoid the
serialization overhead. But how do you implement concurrent traversals
without private "seen" tables? (e.g., if the graphs overlap, one of the
traversals will find the other traversal's visited flag and fail to
visit the entire graph.) Reentrant traversal again. Pathological case:
$aa = [1];
$ab = [1];
%ha = ( a => \$aa, b => \$ab );
%hb = ( a => \$ab, b => \$aa );
# %ha and %hb overlap and are deep-identical,
# but not deeply reference-identical.
Comparing serialized object graphs strikes me as tremendously esoteric,
e.g. a maintenance burden to be used by very few clients. (One of the
few significant uses being that of replacing string-equals for the
testing of the serializer itself.) It also strikes me as very, very,
very complicated should the "freeze methods" diverge even slightly. I've
never seen any such mechanism in any other environment. To compare
graphs that I had saved in long-term storage, I as a caller would expect
to need to deserialize the graphs and use a deep equals--and I would
expect to implement deep equals (another feature I've never before seen
as a specific feature of any environment) by serializing the
deserialized graphs again and doing a string (or file) comparison. E.g.,
if I had read $a or $b from a file, I would expect to have to:
freeze(thaw($a)) eq freeze(thaw($b))
instead of:
$a eq $b
That synthesizes the functionality from a minimal set of
operations--freeze and thaw--and with a lot less maintenance for parrot.
(At the cost of a bit of memory and runtime speed. But anybody who
performs deep-compares in truly performance-critical code needs to meet
my Clue Bat[tm].)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
