On Thu, 06 Mar 2003 05:51, Austin Hastings wrote:
> You'd like to declare the relationship between them, but this can be
> really difficult (consider e.g., nethack, in which the things you can
> "own" are constrained by weight/volume/knapsack).
> So certainly you need to be able to add code to the equation.
> Person::possess(o is Object)
> {
> if (weight_of_my_stuff() + weight_of(o) > $self.weight_limit)
> {
> whine(...);
> }
> else
> {
> $self.stuff.push(o);
> }
> }
No, that's not a part of the association. That's like asking `push' to do
that checking for you.
With the current pre-release version of Class::Tangram you could do that by
overriding, Person->set_stuff, which would be called by
Person->stuff_insert with the new contents of the container as an
argument. It is the job of the set_stuff method to check for the
differences and do relevant modifications to the internal state of the
object, or to raise exceptions if the new container contents are not up to
scratch.
This may seem inefficient, but I consider it a starting point of the
implementation (like the original version of Class::Tangram, which was
implemented with AUTOLOAD and regexp, and took about 20 lines of code
;-)). It seemed cleaner than requiring classes to overload all of
Person->stuff_insert(), Person->stuff_replace, Person->stuff_clear(), etc.
> In other cases, you don't care so much. So then it would be nice if you
> could declare the relationship and have the accessor functions get
> generated for you.
Well, use Class::Tangram then :-).
> I work with a tool that provides just a little built in support for
> this kind of thing:
> When you create a relationship (using the "relate" command) between to
> objects, you can do:
> ccm relate -from $object_spec_1
> -name $relationship_name
> -to $object_spec_2
>
> ccm unrelate [spec, as above]
>
> ccm relate -show [partial or complete spec, as above: -f -t -n]
>
> ccm query "is_<relationship_name>_of('$object_spec')"
> ccm query "has_<relationship_name>('$object_spec')"
>
> The relate database is pretty straightforward -- a three-column table.
Also known as a `link table'. How many columns it has, and whether it
shares a table with either related object (like a foreign ID column),
depends on the multiplicity of the relationship.
> The query part is supported by "magic" -- the query syntax parser knows
> how to chop up is_XXX_of() and has_XXX() predicates to extract
> relationship names.
Tangram inserts special tied variables that have the information needed and
`auto-vivify' by loading the collection from storage when accessed. Very
transparent :-).
> I think that the Association concept can be implemented as a non-core
> package. You'll declare Associations like classes, except that they'll
> mostly be auto-generated. However, if you need to insert code (as
> above) you can explicitly spell out your sub.
Certainly they could.
> What would be nice would be a convention for
> accessing/creating/querying/modifying them, so that whenever we see
> "is_AssociationName_of(...)" (or whatever) we know that this is an
> association.
This is a key point.
--
Sam Vilain, [EMAIL PROTECTED]
If you think the United States has stood still, who built the
largest shopping center in the world?
RICHARD M NIXON
