4 ms·

Odin looks extremely appealing to me, but I am quite sad about the lack of methods, or more specifically, lack of guarantees about "dot-autocomplete" support in

Odin looks extremely appealing to me, but I am quite sad about the lack of methods, or more specifically, lack of guarantees about "dot-autocomplete" support in mainstream code editors. But I do think methods make code more concise and readable too ( object_verb(obj) vs. obj.verb() ). They are syntactic sugar worth having. In 2023, tooling is at the point where RTFM is secondary for mainstream lang libraries (TFM being embedded into the editor in intelligent ways). I will not go back.

nrabulinski 3y ago
Editor suggestions are good enough when you know what you’re looking for or can guess where the method you’re looking for will be and what it will be called. You very much still need to RTFM if you don’t have neither
- pphysch 3y ago
  So let's say I'm using some new SDK. I run a method that returns a Service object. In my current Go/Python world, I can dot-autocomplete to quickly get an idea of what procedures I can perform with this object. 90% of the time, this is sufficient to proceed. 10% of the time I need to RTFM/SO.
galaxyLogic 3y ago
Method-syntax is more than syntactic sugar. It is not just about getting a function from an object and then executing that function. It is executing that function in the context of the object from which you get it, by utilizing the pseudo-variable "this" (or 'self' in Smalltalk) which refers to that object from which you got that function (a.k.a "method" in this case). But definitely the ability to have editor-support for lookup of argument-types etc. is a great benefit too.
- munificent 3y ago
  > It is executing that function in the context of the object from which you get it, by utilizing the pseudo-variable "this" (or 'self' in Smalltalk) which refers to that object from which you got that function (a.k.a "method" in this case). Ignoring runtime polymorphism for the moment, there's nothing special about "this" or "self". It's just another function parameter. Consider how in Python it is actually explicitly declared as a parameter in the method declaration.
  - masklinn 3y ago
    That is not necessarily the case though, for instance in Self (the language) `self` is the parent slot of the method activation object which contains the instance to which the message resolved. Then again there's no to functions as I don't think Self has free functions. Also lots of languages have syntactic sugar around the corresponding object e.g. implicitly dereference it for attribute access and method calls, or even give it exclusive(ish) properties like @ in Ruby (or straight up instance variable access in smalltalk). Even Python treats it specially, given a method `foo`, `obj.foo` actually returns a proxy object which partially applies `foo` to `obj`. This only works on functions defined on the class object, mere callables set on the instance don't get that treatment.
    - munificent 3y ago
      > Also lots of languages have syntactic sugar around the corresponding object e.g. implicitly dereference it for attribute access and method calls The parent comment specifically said "by utilizing the pseudo-variable 'this' (or 'self' in Smalltalk)", so I was referring to that. Yes, in languages where the receiver is implicitly added to the lexical scope chain, things get a bit more complex. > or even give it exclusive(ish) properties like @ in Ruby (or straight up instance variable access in smalltalk). Even Python treats it specially, given a method `foo`, `obj.foo` actually returns a proxy object which partially applies `foo` to `obj`. This only works on functions defined on the class object, mere callables set on the instance don't get that treatment. Sure, there's other features that object-oriented languages tend to hang off methods too, but my point was just that from the perspective of within a method body, the receiver's mostly just another parameter. This is made explicit in some languages: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
  - mathisfun123 3y ago
    In python you get more than just a self - you get easier access to the inheritance hierarchy - super() is actually a compiler supported language feature (the compiler secretly inserts the parent class intro the parens).
  - 3y ago
- wtetzner 3y ago
  > Method-syntax is more than syntactic sugar. No, method syntax is just syntax. In some languages methods are more than just syntax sugar, but there's nothing special about the syntax itself.
  - galaxyLogic 3y ago
    Syntax has no meaning unless it is associated with some semantics, like it is in all programming languages.
    - wtetzner 3y ago
      The point is that the semantics could very well be just an alternative form of function calls.
      - galaxyLogic 3y ago
        It could be, but it is not. In JavaScript you can say: let v = myOb.myFunk(); or you can say: let v2 = myFunk.call (myOb); Those the two different syntaxes you can use to make a method-call. They have the same result for all arguments. So you can say one is syntactic sugar over the other. Their semantics are the same. In other words they have the exactly same meaning. BUT if you write: let v3 = myFunk(); the result is different. And you get an error if your source-code assumes that 'this' is not undefined. That shows that the semantics of the 3rd example above is different from the semantics of the first two. In other words the semantics of a function-call and of a method-call are different. Therefore, we can say that method-call is not syntactic sugar for doing the same thing as a plain function-call.
        wtetzner 3y ago
        Except we were never talking about JavaScript. I thought the OP made it pretty clear that they only cared about the syntax of method calls because they flow nicely and more easily support auto-complete in editors. Simple syntax sugar that translates `foo.bar(x, y)` into `bar(foo, x, y)` would suffice for both.
PHTest 3y ago
IIRC, the odin language server now has method "dot-autocomplete" support that will reformat it into the function call with the variable as the first parameter. https://github.com/DanielGavin/ols https://github.com/DanielGavin/ols

nrabulinski 3y ago

Editor suggestions are good enough when you know what you’re looking for or can guess where the method you’re looking for will be and what it will be called. You very much still need to RTFM if you don’t have neither

pphysch 3y ago
So let's say I'm using some new SDK. I run a method that returns a Service object. In my current Go/Python world, I can dot-autocomplete to quickly get an idea of what procedures I can perform with this object. 90% of the time, this is sufficient to proceed. 10% of the time I need to RTFM/SO.

galaxyLogic 3y ago

Method-syntax is more than syntactic sugar. It is not just about getting a function from an object and then executing that function. It is executing that function in the context of the object from which you get it, by utilizing the pseudo-variable "this" (or 'self' in Smalltalk) which refers to that object from which you got that function (a.k.a "method" in this case). But definitely the ability to have editor-support for lookup of argument-types etc. is a great benefit too.

munificent 3y ago
> It is executing that function in the context of the object from which you get it, by utilizing the pseudo-variable "this" (or 'self' in Smalltalk) which refers to that object from which you got that function (a.k.a "method" in this case). Ignoring runtime polymorphism for the moment, there's nothing special about "this" or "self". It's just another function parameter. Consider how in Python it is actually explicitly declared as a parameter in the method declaration.
- masklinn 3y ago
  That is not necessarily the case though, for instance in Self (the language) `self` is the parent slot of the method activation object which contains the instance to which the message resolved. Then again there's no to functions as I don't think Self has free functions. Also lots of languages have syntactic sugar around the corresponding object e.g. implicitly dereference it for attribute access and method calls, or even give it exclusive(ish) properties like @ in Ruby (or straight up instance variable access in smalltalk). Even Python treats it specially, given a method `foo`, `obj.foo` actually returns a proxy object which partially applies `foo` to `obj`. This only works on functions defined on the class object, mere callables set on the instance don't get that treatment.
  - munificent 3y ago
    > Also lots of languages have syntactic sugar around the corresponding object e.g. implicitly dereference it for attribute access and method calls The parent comment specifically said "by utilizing the pseudo-variable 'this' (or 'self' in Smalltalk)", so I was referring to that. Yes, in languages where the receiver is implicitly added to the lexical scope chain, things get a bit more complex. > or even give it exclusive(ish) properties like @ in Ruby (or straight up instance variable access in smalltalk). Even Python treats it specially, given a method `foo`, `obj.foo` actually returns a proxy object which partially applies `foo` to `obj`. This only works on functions defined on the class object, mere callables set on the instance don't get that treatment. Sure, there's other features that object-oriented languages tend to hang off methods too, but my point was just that from the perspective of within a method body, the receiver's mostly just another parameter. This is made explicit in some languages: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
- mathisfun123 3y ago
  In python you get more than just a self - you get easier access to the inheritance hierarchy - super() is actually a compiler supported language feature (the compiler secretly inserts the parent class intro the parens).
- 3y ago
wtetzner 3y ago
> Method-syntax is more than syntactic sugar. No, method syntax is just syntax. In some languages methods are more than just syntax sugar, but there's nothing special about the syntax itself.
- galaxyLogic 3y ago
  Syntax has no meaning unless it is associated with some semantics, like it is in all programming languages.
  - wtetzner 3y ago
    The point is that the semantics could very well be just an alternative form of function calls.
    - galaxyLogic 3y ago
      It could be, but it is not. In JavaScript you can say: let v = myOb.myFunk(); or you can say: let v2 = myFunk.call (myOb); Those the two different syntaxes you can use to make a method-call. They have the same result for all arguments. So you can say one is syntactic sugar over the other. Their semantics are the same. In other words they have the exactly same meaning. BUT if you write: let v3 = myFunk(); the result is different. And you get an error if your source-code assumes that 'this' is not undefined. That shows that the semantics of the 3rd example above is different from the semantics of the first two. In other words the semantics of a function-call and of a method-call are different. Therefore, we can say that method-call is not syntactic sugar for doing the same thing as a plain function-call.
      - wtetzner 3y ago
        Except we were never talking about JavaScript. I thought the OP made it pretty clear that they only cared about the syntax of method calls because they flow nicely and more easily support auto-complete in editors. Simple syntax sugar that translates `foo.bar(x, y)` into `bar(foo, x, y)` would suffice for both.

PHTest 3y ago

IIRC, the odin language server now has method "dot-autocomplete" support that will reformat it into the function call with the variable as the first parameter. https://github.com/DanielGavin/ols https://github.com/DanielGavin/ols