4 ms·

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 previousl

• AnimalMuppet 4y ago
  That sounds like no fun() at all. Right, I'll show myself out...
• __jem 4y ago
  In Rust, it's still qualified by the type you're calling it on, which I assume is also the case in other languages.
  • masklinn 4y ago
    > 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".
• masklinn 4y ago
  > doesn't that cause ambiguity with a previously imported global function fun()? Yes, although overloading can mitigate the issue.
  • elcritch 4y ago
    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.
• Yujf 4y ago
  In rust you can do this but they are namespaced with the name of the struct. So you can do Object::fun(obj)
  • CGamesPlay 4y ago
    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.
• lalaithion 4y ago
  If you have two functions abracadabra(foo) and foo.abracadabra() which do different things, you should rename one of those functions tbh.
  • feoren 4y ago
    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.
    • ilyt 4y ago
      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)
    • jdmichal 4y ago
      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.
    • lalaithion 4y ago
      It doesn't have to be dynamic dispatch; you could also do static dispatch at compile time based on type information.
• j-james 4y ago
  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.
• tsimionescu 4y ago
  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)?