You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor special case for how canonical enclosing containers are calculated
There is some complicated logic in the calculations for determining a canonical
enclosing container, when we find ourselves examining a "hidden" interface. The
list of "hidden" interfaces, which we should not consider when determining a
canonical enclosing container, is exactly one: `Interceptor`. But it's
important that it stay buried.
The logic was hard to read, so first, I split out a complicated if-condition
into a few local variables. The logic also needs to track the "current"
container in the inheritance list, and the "previous", and the "previous
visible." This was complicated when using a for-in loop. I changed it to use a
standard for loop with indices.
Then I saw that we only ever find outself asking a container for it's
"memberByExample" in the case when we're looking for one of Object's members
(`toString`, `noSuchMethod`, `operator ==`, `hashCode`, and `runtimeType`. We
can inline the logic to fetch a member by example. This allows us to delete a
late field on every Container.
Also, the package graph `_invisibleAnnotations` and `_inheritThrough` fields
had very complicated initializers which I simplified with if-elements.
0 commit comments