Maybe throw instead? I see you already have a few if (PlatformViewNoClip) do nothing. If this code is reached, maybe it's a bug?

I guess it doesn't really matter, but this seems like a more consistent and sane behavior to me than throwing. Sure, the surrounding code never calls this, but that happens to be an implementation detail of the surrounding code and not a contract of this class itself.

It's a sealed class hierarchy, so I think it can be other.runtimeType == PlatformViewNoClip.

PS: Also shocked to learn that the language doesn't do identical check automatically. It would be so much cheaper to do it before calling the polymorphic operator ==.

same here: could be PlatformViewNoClip.hashCode, maybe even just 42 :)

I think I actually tried this, but PlatformViewNoClip.hashCode doesn't actually work because the language will attempt to call a static method called hashCode which doesn't exist. I also feel like hashing the runtime type is better than assigning an arbitrary value, because some other equally cute person might return 42 for their class which is also a singleton type, and if they end up in a very generic (i.e. <Object>) hashed collection together they will have a hash collision. Is this class likely to be put in a hashed collection with other random singleton classes? No. In practice it isn't even put in a hashed collection at all, but the language wants me to implement this if I implement operator==, so this is all theoretical and probably will never matter anyway.

nit: the as prefix usually implies a view over another object. However, this returns a new path, i.e. it's a conversion to a path. For that we usually use the to prefix, i.e. toPath.

Good point. I'll change it.

Can you please leave a comment for the future Yegor, who is going to come here feeling all clever and replace it with rect.contains(other) and cause a bug because this logic is inclusive on all sides, but Rect.contains is exclusive at right and bottom?

Actually I think we should use rect.contains. I'm not sure why I didn't just use it here.

Ah, the reason I didn't use it is because rect.contains(ui.Rect) doesn't exist. rect.contains takes a single offset.

nit: s/an/a/

A doc comment explaining who is responsible for calling this method would be helpful.

nit: it's ok to omit types in new code (or maybe even drive-by remove unnecessary types in existing code).

Do we still need the SVG registry? According to MDN Safari implemented clip-path: path(...) in 13:

https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path

Omg seriously? Ugh, I can't believe I spent all this effort writing this class and implementing disposal methods and stuff, haha. I'll remove this and simplify.

The function could instead return null, and the place that applies the clip could avoid setting the property to an empty string unnecessarily.

The container can be reused when the styling changes, so we actually do need to set the property to an empty string if the clipping goes away.

Debug print leftover?

Whoops I'll remove it