4 ms·

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 instan

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

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