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.
