If they're sufficiently leaky abstractions to get the necessary data to implement said function without implementing it as a methods/member function, then I tend to favor the independent free-standing language in languages that support it.
Otherwise, I tend to favor the direction that seems to produce more desirable coupling. A common example that crops up in my field is whether an object should be able to draw itself to an (abstract) renderer or whether the renderer should be able to draw the object. There are merits both ways. Don't let people say one way is always superior to the other.
But the question should be about coupling as I see it. It revolves around who should know more. It's about the flow of knowledge. If the object has a method to draw itself, it requires a lot of knowledge of the renderer even if it's very abstract. Chances are that it will need to know about things of the renderer like how to draw lines, rectangles, images, maybe a canvas, possibly even clipping, etc. If the renderer changes its interface, it can break all code in such objects. If it's the other way around and the renderer has the functionality, it will probably need to know a lot about objects like their positions on the screen, what sort of thing they are, etc. If those objects change in their interfaces, then it breaks the renderer.
From my perspective, dependencies should flow towards stability (what is less likely to change in the future), since unstable dependencies tend to produce cascading changes that cost far more than they should. So it is the thing that you anticipate is more stable (or at least more confident about) in its interface that should know more about the outside world in its implementation, not the other way around, to minimize maintenance costs (i.e., the cost of changes). If the object knows how to draw itself, the renderer interface should be very stable. If the renderer instead knows how to draw these objects, then interfaces of said objects should be very stable.
One of the reasons I think many people tend to say that objects knowing how to render themselves is an anti-pattern is because there are typically fewer concrete renderers than there are objects that can be rendered. And that's worth factoring into account. But it makes little difference if the dependencies are flowing towards a very stable direction.