Hacker News Reader

Comment by tremon | Hacker News Reader

and vice-versa

Doesn't the reverse pollute the function namespace? If every obj.fun() can be written as fun(obj), doesn't that cause ambiguity with a previously imported global function fun()?

View on HN

In rust you can do this but they are namespaced with the name of the struct. So you can do Object::fun(obj)

You can also `use Object::*` to be able to do this without prefixing. Also, you can throw use statements into functions, so this is pretty useful in specific cases.

In a language without function overloading or namespaces/modules, yes, it would be a major limitation.

But since most languages have both, I don't think it's a serious concern. I don't know of any language where the only names pace support is classes, so that all functions go in a global namespace unless they are methods on a class - maybe you could argue C works like this (where "methods" are function pointer member of a struct)?

Not unless the function signatures overlap entirely. That's rare enough that I don't think I've ever? encountered it in several years of writing Nim.

> doesn't that cause ambiguity with a previously imported global function fun()?

Yes, although overloading can mitigate the issue.

Yah I ran into that issue more in Julia. There's a built-in function to help find clashing functions.

In Nim however I've only had it happen a handful of times in a few years. Then you just need to use the module name to qualify it, or change your imports.

That sounds like no fun() at all.

Right, I'll show myself out...

If you have two functions abracadabra(foo) and foo.abracadabra() which do different things, you should rename one of those functions tbh.

The problem is when you have the functions:

Square.computeArea()

Circle.computeArea()

Clearly these should do different things. I suppose "computeArea(shape)" does dynamic dispatch based on the type of shape? But you're still putting every function defined on every type in your entire codebase in a global namespace. It's not obviously awful but I'd definitely be a bit nervous about it.

I dunno, I kinda like that, add sum types and you can pass anything to computeArea.

The problem really starts when you have

typeA.func()

typeB.func(x)

typeC.func(x=default_value)

You only need dynamic dispatch if dynamic types are involved. If you can always resolve to concrete types, then you can statically resolve the required function.

It doesn't have to be dynamic dispatch; you could also do static dispatch at compile time based on type information.

In Rust, it's still qualified by the type you're calling it on, which I assume is also the case in other languages.

> which I assume is also the case in other languages.

Nope. Rust has an extremely restrictive form of UFCS. In fact officially it's not called UFCS, but "Fully Qualified Path syntax".

Reply on news.ycombinator.com