Re: Dependency / Constraint patch

On Tue, 2002-06-25 at 20:34, Tom Lane wrote:
> > The confusing part is that we deal primarily with the supporting objects
> > while dealing with the dependency.  Perhaps better naming would be
> > 'supporter' (dependee) and 'supportee' (depender) which reverses the
> > logic -- more conventional?  That is, pass around the opposite of a
> > dependency.
>
> Hmm, that might help.  I was thinking of "depender" and "master".

Thats not so bad.  Either would do.

> > Perhaps simply supporter and depender?

> Another line of thought is 'referencer' and 'referencee', since in

I'd expect this to have similar issues as depender and dependee in
implementation.

> > I was considering createDependency(this, that) myself.  dependsOn seems
> > like it should be:
>
> > this->dependsOn(that);
>
> Yeah, it would work better in a C++-ish syntax, but we don't have that
> luxury.  My problem with either dependCreate or createDependency is that
> they don't give you a cue about the argument ordering, and with such an
> easily-reversed relationship I think a cue is important.

Thats fair.

> I'm also somewhat uncomfortable with the notion of "implicit
> dependencies" (alwayscascade = true) that you've invented; this seems
> like a bad idea to me, but I haven't quite worked out why I don't like
> it.

Certainly allows for removal of a large portion of the 'drop this too'
code that was lying all over the place.  The theory is those were
completely hidden items with special support code.  I saw an oppertunity
to remove some of the 'special' from it.


Did you want a new patch with the above changes applied?  I would expect
a direct string replacement would do the job.