Martin D Kealey wrote:
On Mar 27, 2010, at 15:43 , Darren Duncan wrote:
For example, say you want to define a graph of some kind, and for
elegance you have a separate container and node and side classes,
On Sat, 27 Mar 2010, Brandon S. Allbery KF8NH wrote:
This sounds like a hackaround for an incomplete implementation of ADTs.
No, it's simply a reflection that the one-to-one relationship between the
attributes of a single storage object is too simplistic to use as the *only*
encapsulation boundary.
Of course, that points towards having access limits that depend not just on
the type, but on the specific object: in Darren's example, nodes should be
able to see the details of the edges and faces they're attached to, but
probably not any other edges or faces. And definitely not the edges or faces
in some completely disconnected mesh or network.
I agree. And in my experience actually implementing said graph thingy, one of
the things I regularly had to test is whether an object I was given as an
argument is in the same network as another one, and the easiest way to do that
is to test if both have the same container object.
FYI, that graph implementation was the now-deprecated
http://search.cpan.org/~duncand/Rosetta-v0.71.0/lib/Rosetta/Model.pm (aka
SQL::Routine), last substantially updated in mid-2005. This url is a Perl 5
version, but I had also ported it to Perl 6 in the first few months of Pugs'
existence to help test Pugs, though it was soon after wiped from Pugs' repo, as
they added the policy that most ext/ things should actually be distributed
separately from Pugs, or there was some reason.
-- Darren Duncan
A connected mesh or network is a reasonable ADT, but to implement it you're
going to want several classes. The mesh-object-as-a-whole is the appropriate
encapsulation boundary.
If we had a really sophisticated ADT that could represent a "Network", that
would indeed solve the encapsulation problem. So what tools are we going to
need to build such an ADT? Well, privacy, trust, ...
-Martin
