5 ms·

> Syntax - UFCS (Uniform Function Call Syntax) UFCS is such an underrated language feature. When you have UFCS you can toss out 90% of the uses of methods in f

• jayd16 1y ago
  If all you're doing is accessing public members, sure.
  • WalterBright 1y ago
    It works for all functions that have parameters, `f(a)` and `a.f()` are equivalent.
    • jayd16 1y ago
      Yes, but I presume that f() cannot access private members of a.
      • WalterBright 1y ago
        That's correct.
  • nicwilson 1y ago
    `private` is only private to the module, not the struct/class, (In other words, all functions in the same module are all C++ style `friend`s) and so free function in same module work.
• layer8 1y ago
  Dot syntax tends to work better for code completion, though. In addition, without uniform call syntax, adding a new method can only break subclasses, whereas with uniform call syntax it can break other client code.
  • Doxin 1y ago
    There's nothing preventing UFCS from working with code completion. e.g. given: int addOne(int v){ return v+1; } You can now write code like this: int foo=3; writeln(foo.addOne); There is absolutely no reason that typing "foo." would not suggest "addOne" as possibility.
    • layer8 1y ago
      My comment was about the reverse, using function syntax for methods. Furthermore, I don’t think it necessarily makes sense for all functions that happen to take, say, a string as their first argument, to be listed in the code completion for method invocation on a string variable. If you merely want to define auxiliary methods outside of a class, which is the thing the GP seems to like, that’s what’s usually called “extension methods”. It doesn’t require uniform call syntax.
      • Doxin 1y ago
        > using function syntax for methods hmm, yeah fair enough I suppose. I don't think I've found a good use-case for that yet. I guess having the symmetry there makes the feature easier to explain at least? I dunno. > Furthermore, I don’t think it necessarily makes sense for all functions that happen to take, say, a string as their first argument, to be listed in the code completion for method invocation on a string variable. All functions in scope that happen to take a string as their first argument. If this turns into an actual problem in practice it's quite doable to refactor things such that it's not an issue. I find that when I use autocomplete I'll be typing the first bit of the method name in any case. I never "browse" autocomplete to look for the thing I need. Extension methods are another way to do the same thing yes, but that feels like special-casing behavior, where UFCS is more general. With extension methods you need to think of how to implement it wrt things that don't usually have methods attached. With UFCS that just works the way you'd expect it to.
      • jasperry 1y ago
        I agree with this. I'd go even further and say that dot syntax should only be used to access things that are /actually a part of the object/, whether record fields or methods. If you use the dot for everything just because it's convenient, you're making the code structure harder to understand by syntactically conflating different mechanisms.
• kmarc 1y ago
  Reminds me of vim script's implicit method syntax [1] Eg. any function call can be converted to a method call on the function's first parameter: let mylist = [3, 2, 1] " prints "1" as these two are equivalent echo sort(mylist) == mylist->sort() Helps a lot with chaining.
  • kyleee 1y ago
    Quirky and awesome
    • kmarc 1y ago
      If you think about it, it's the mirrored version of python object/class methods: they receive the object (self) / class (cls) as the first parameter. Same with Rust's trait impl's methods.
• girvo 1y ago
  I was about to say "Yeah, its my favourite feature of Nim!" and then I realised what account I was replying to ;)
  • elcritch 1y ago
    Haha, Nim is my preferred UFCS language.
• pjmlp 1y ago
  OO support is more than just record.method(), which is something you don't even have in OOP systems based in multi-dispatch.
  • sirwhinesalot 1y ago
    I always find it funny how people focus on the .method() syntax. You have the "pipe" operator in some functional languages that achieves the same thing, pass the result of an expression as the first argument of the chained call on the right. Nothing to do with OOP.
    • pjmlp 1y ago
      I think it needs a higher level experience across procedural, logical, functional and object based languages, the unique ways each one applies ideas into their programming model, how that interacts to CS, for finally understanding how those concepts come together, instead of being so fixated in language syntax.
    • xigoi 1y ago
      This is because in languages that don’t have UFCS, methods are often abused to create “natural” looking syntax like expect(6).toBe(even)
• motorest 1y ago
  > When you have UFCS you can toss out 90% of the uses of methods in favor of just plain ole functions. Can those go away if you use inheritance or polymorphism, and you need your functions to access protected or private members? I mean, OO is as much about methods as functional programming is about functions.
  • zozbot234 1y ago
    Implementation inheritance is generally a misfeature, especially in modern languages with proper generics. If you insist on having it, you can replicate it manually by using interface inheritance and the generic typestate pattern.
    • motorest 1y ago
      > Implementation inheritance is generally a misfeature (...) Not really. It's value proposition is code reuse. It's not a misfeature just because it breaks a simple explanation.
      • elcritch 1y ago
        You get about as much reuse from a set of re-usable functions as you get from inheriting implementations. Though I grant that having an object hierarchy does make it a bit more explicit what’s being inherited or needs implementing. However, a OO hierarchy also tends to obscure the actual parent implementations as well. Just having a set of functions from a module generally lowers the number of indirections. In general I find working through a non-OO code base generally easier to grok and understand. Especially the OP culture from Java or C# style OO, even if I’m generally good at understanding OO patterns.
        • galangalalgol 1y ago
          Ok, this is what I was trying to say in my sibling post, but without the snark and including the why.
        • motorest 1y ago