Death to recursion! Re: Child vs parent records

[Ed Kleban]

On 12/11/05 8:44 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/11/05 3:30 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>>> I like this example:
>>> 
>>>     Table Person with recursive link HaveBorn
>>> 
>>> So we have here in fact link 2 : M which still is M : M.
>>> Right?
>>> 
>>> Now let we take Person with RecId = 1024,
>>>  Let this will be Ruslan.
>>> 
>>>         res = Born.FindLinked( 1024, Person, Person, ???? )
>>> 
>>> So whom you want find?
>>> 
>>> A) Children of Ruslan:
>>> 
>>>     childs = Born.FindLinked( 1024, Person, Person, kFromPArentToChilds)
>>> 
>>> b) Children of Ruslan:
>>> 
>>>      parents = Born.FindLinked( 1024, Person, Person, kFromChildsToParent)
>>> 
>> 
>> Based on this response, my guess is that that what you mean by this is the
>> same as:
>> 
>>      FindLinked( inRecID, inTableA, inTableB, anEVRecursionDirection )
>> 
>> Where:
>>         EVRecursionDirection.kFromParentToChild means kGetTableALink
>>            implying that inRecID is aTableBRecId
>> 
>>         EVRecursionDirection.kFromChildToParent means kGetTableBLink
>>            implying that inRecID is aTableARecId
>> 
>> If you say this is true, then I now understand how FindLinked works and I
>> will define these constants and ignore all of the discussion of recursion in
>> the documentation -- which I believe is irrelevant, confusing, and
>> unnecessary.  
>> 
>> If you say this is not true, then I am still confused.
> 
> This is other side of truth.
>   
> This LAST parameter is required only for recursive link. We have told about
> this before. When you have 2 table Left and Right all is simply.

Yes, I understand.  But if you have a syntax of either:
  
    FindLeftLink( rightRecID )
    FindRightLink( leftRecID )

or if necessary:

    FindLinked( inRecID, EVLinkSide )

    where EVLinkSide.kGetLeftLink returns a left link.
    and   EVLinkSide.kGetRightLink returns a right link.

Then: 
    1) You do not need to list the Tables.
    2) You do not need a special argument for the recursive case.
    3) The syntax of the Find command does not impose an artificial
       restriction on how to define your links in order to make sure
       that kFromParentToChild works correctly.
    4) The syntax makes it very clear which table the returned RecIDs
       in VArraySet will come from.


> YES, you CAN think about recursive table as about 2 tables.
> 
> 
> But we use recursion params and description in docs BECAUSE
> you HAVE RECURSIVE link in fact.
> 
> The TIP: "I can think about it as 2 tables", do not eliminate fact of
> recursive nature if link.
> 
> You see?
> 
Yes.  I see and I understand and I agree.  I am a big fan of Recursion.  I
like it a lot. I use it every day.  Talking about the recursive case when
TableA = TableB as a side comment in the documentation for clarification or
to be informative is a fine thing.

But providing a syntax that makes it necessary to think in these terms,
(unfortunately compounded by unclear documentation that doesn't explain how
to define your table so that the EVRecursionDirection values will work
properly) is overly complicated and unnecessary in my opinion.

And providing a powerful, generalized BinaryLink mechanism that can be used
to define 1:M, M:M, M:1, and 1:1 links... but then telling the user

    "Oh but if you have M:1 in your mind change it to 1:M in the call to
     CreateBinaryLink or else the EVRecursionDirection parameters will work
     wrong when you call FindLinked."

is limiting, unnecessary, and offers the potential for confusion and error.

My subject should not have been "Death to Recursion!"  it should have been
"Death to Inconsistent nomenclature in functions that define a link from
from functions which use a link".

But  "Death to Recursion!" is shorter and has a nice ring to it.  It got
your attention, didn't it ?

;-)

--Ed