Spread of delegates through outer patch issue

vvvv beta bug
1

I’ve found what I think is a bug with delegates.

This only seems to occur with delegates which have at least one input and one output, and where one of those is a spread.
If you have a spread of delegates you can’t connect them through an ‘outer’ patch.

It looks like it’s caused by a subtype being ‘sequence’ instead of spread, but because that subtype is inside the delegate type description it’s not being matched by the input pin. If that makes sense? Best to have a look at the attached patch.
VLDelegateTypeOuterPatchIssue.zip (8.2 KB)

2

A workaround is making the patch that holds the invoke and the patch that holds the delegate both generic

3

the workaround makes sense. Internally each link gets translated to a type constraint, where the source type needs to be assignable to the sink type, but not necessarily equal to…
Making those patches generic is a bit like keeping all of the original constraints and dragging them to the outer patch. By making the patches generic you disallow premature simplifications on the types and tell the outer patch to solve all type constraints that were collected.

it looks like in the example it suffices to have the upper patch generic.

other workarounds with ungeneric patches:

  • just make sure the types are actually equal. in DelegateLibrary annotate Input to be of type spread (now the types match exactly → all good) or
  • go DoInvokeLogicB, put a ToSpread [Sequence] between input and GetSlice. Now because of some nerdy co/contravariance features of IEnumerable<> and Func<> these different types are assignable to each other. However i would prefer the easy way… Also this way is doing more than the original patch (tospread needs to be computed…)

so pick the first choice or make it generic.

EDIT: and further…
i can understand that you typically don’t want to be confronted with those issues.
our idea was: by making the patch generic by default you shouldn’t have to deal with those problems.
however i can understand that the readability of types suffers when they get too generic.
so i can understand you turning off this feature. basically it’s an open quest how to combine maximum generic behavior with readability.
still i wouldn’t qualify this behavior as a bug.

4

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.