--- Begin Message ---
> For instance, now I have this implemented :
>
> ef2_Spheres_Elastic_ElasticLaw(..., bool allowDelete=true)
> {
> ...
> if (allowDelete) requestDelete;
>
> }
>
> It works. But if later I want to switch to Law2_Dem3Dof_Elastic_Elastic, I will have to make the same change in this one again. Functors have to be modified one by one, that is what I meant.
Yes, unless you put it to ConstitutiveLaw itself, which, as I said, is
perhaps not generally useful. But that change is rather trivial in most
cases.
> Haha! Why would neverErase be better than allowDelete or eraseSometimes?
> English grammar matters? ;)
Just for consistency sake; if we call it requestErase, it would be
bizzare to have allowDelete; and the "never" makes it clear when that
will happen. ("sometimes" is long and feels like that arbitrarily
sometimes we erase, sometimes not; and "allow" would suggest that
erasing interaction is something exceptional).
> >> For this purpose, the function "requestDeletion" could be replaced by
> >> "requestKeep", and all interactions would be deleted unless *at least
> >> one* constitutive law decides otherwise. In this case, the
> >> "allowDelete" flag is not needed any more.
> >>
> > Wouldn't work, since the collider would have to traverse many more
> > interactions at every step and track which ones were not requestKeep'd
> >
> Mmmmh. The collider already traverse all interactions right
No, it doesn't (neither PersistentSAPCollider did, FYI). It only sees
when there is inversion (i.e. 2 bboxed did not overlap and overlap now
or vice versa, along any axis); that's why we needed requestErase (which
remembers the interaction), instead of just setting some interaction
flag inside the interaction itself.
v
--- End Message ---
