7 ms·

You know, I've been thinking about this kind of thing lately. All of this mixin, traits, monkey patching hoopla is completely nonexistent in functional programm

by ryeguy 14y ago

You know, I've been thinking about this kind of thing lately. All of this mixin, traits, monkey patching hoopla is completely nonexistent in functional programming languages. To add a new method to an object you just..write a function that takes that piece of data. Imagine a language where a call looked like this: user.doSomething(1, 2, 3) But it's just syntax sugar for this function application: doSomething(user, 1, 2, 3) ("user" would be just the data..like a struct type thing) That way you get the flexibility of loose functions but you get the (imo) superior aesthetics of oop languages.

zzzeek 14y ago
how is that not what Python already is: >>> class Foo(object): ... def __init__(self): ... self.x = 1 ... self.y = 2 ... def bar(self): ... return self.x + self.y ... >>> Foo().bar() 3 >>> f = Foo() >>> Foo.bar(f) 3 >>>
- Tuna-Fish 14y ago
  But you cannot do it the other way, eg: def foo(bar, baz): print bar.baz + baz f = Foo() f.foo(3) # error
  - zzzeek 14y ago
    Claiming "f.foo" should work when "foo" is a freestanding function strikes me as nonsensical, as the "." operator is a namespace operator, suggesting names that are within the namespace of "Foo". Though Postgresql supports this pattern (http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFUNC-SQL-COMPOSITE-FUNCTIONS http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFU...). I think it's awkward there too, and has the caveat "it's unwise to give a function that takes a single composite-type argument the same name as any of the fields of that composite type." - basically it breaks namespacing.
    - swift 14y ago
      In static languages this really isn't a big deal, since you can dispatch based on type. Things definitely get more awkward if you can do things like define new types at runtime, though.
Tuna-Fish 14y ago
That's how it works in D.
draegtun 14y ago
That's exactly how perl5 objects work: package Foo { sub new { my ($class, $bar) = @_; bless {bar => $bar}, $class } sub bar { my ($self, $x) = @_; say $self->{bar} . $x } } my $foo = Foo->new( 'Hello...' ); # method call $foo->bar( 'baz' ); # => Hello...baz # function call Foo::bar( $foo, 'baz' ); # => Hello...baz
simcop2387 14y ago
That's pretty much exactly how it's worked in Perl for a very long time. It's very useful but it can bring in some ugliness if you don't have a strong typing system.
zem 14y ago
d calls this ufcs ("uniform function call syntax"): http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327...
perlgeek 14y ago
Note that the two examples are only the same if all subroutines are global. The difference is that (usually) methods are looked up where the classes are defined, but subroutines are looked up where they are called. So visibility is different in the case of method invocation.
munificent 14y ago
In my language Magpie, function calls can have which ever appearance makes the most sense for the operation: prefix(arg) // for function-like things arg postfix // for "getters" arg infix(otherarg) // for method-like things It's purely a syntactic distinction. Semantically, methods are always multimethods and are not tied to any receiver class. You can freely define new methods that dispatch on existing classes. I find it works really well, though it brings in some unanticipated complexity. You'll really want multimethods or some form of argument-based polymorphism. Also, scoping get a bit more confusing if you want "overriding" to work like you expect across modules. See: http://magpie-lang.org/multimethods.html http://magpie-lang.org/multimethods.html
- skrebbel 14y ago
  Magpie is so lovely, i want to give it flowers. Do you think it'll ever reach something near production equality, or will it "always" be a "toy"?
krichman 14y ago
That's exactly how these OOP languages get translated into C, so the difference would be having a method dispatch table per class or having a global system for multiple dispatch.

by ryeguy 14y ago

zzzeek 14y ago

how is that not what Python already is: >>> class Foo(object): ... def __init__(self): ... self.x = 1 ... self.y = 2 ... def bar(self): ... return self.x + self.y ... >>> Foo().bar() 3 >>> f = Foo() >>> Foo.bar(f) 3 >>>

Tuna-Fish 14y ago
But you cannot do it the other way, eg: def foo(bar, baz): print bar.baz + baz f = Foo() f.foo(3) # error
- zzzeek 14y ago
  Claiming "f.foo" should work when "foo" is a freestanding function strikes me as nonsensical, as the "." operator is a namespace operator, suggesting names that are within the namespace of "Foo". Though Postgresql supports this pattern (http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFUNC-SQL-COMPOSITE-FUNCTIONS http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFU...). I think it's awkward there too, and has the caveat "it's unwise to give a function that takes a single composite-type argument the same name as any of the fields of that composite type." - basically it breaks namespacing.
  - swift 14y ago
    In static languages this really isn't a big deal, since you can dispatch based on type. Things definitely get more awkward if you can do things like define new types at runtime, though.

Tuna-Fish 14y ago

That's how it works in D.

draegtun 14y ago

That's exactly how perl5 objects work: package Foo { sub new { my ($class, $bar) = @_; bless {bar => $bar}, $class } sub bar { my ($self, $x) = @_; say $self->{bar} . $x } } my $foo = Foo->new( 'Hello...' ); # method call $foo->bar( 'baz' ); # => Hello...baz # function call Foo::bar( $foo, 'baz' ); # => Hello...baz

simcop2387 14y ago

That's pretty much exactly how it's worked in Perl for a very long time. It's very useful but it can bring in some ugliness if you don't have a strong typing system.

zem 14y ago

d calls this ufcs ("uniform function call syntax"): http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327...

perlgeek 14y ago

Note that the two examples are only the same if all subroutines are global. The difference is that (usually) methods are looked up where the classes are defined, but subroutines are looked up where they are called. So visibility is different in the case of method invocation.

munificent 14y ago

In my language Magpie, function calls can have which ever appearance makes the most sense for the operation: prefix(arg) // for function-like things arg postfix // for "getters" arg infix(otherarg) // for method-like things It's purely a syntactic distinction. Semantically, methods are always multimethods and are not tied to any receiver class. You can freely define new methods that dispatch on existing classes. I find it works really well, though it brings in some unanticipated complexity. You'll really want multimethods or some form of argument-based polymorphism. Also, scoping get a bit more confusing if you want "overriding" to work like you expect across modules. See: http://magpie-lang.org/multimethods.html http://magpie-lang.org/multimethods.html

skrebbel 14y ago
Magpie is so lovely, i want to give it flowers. Do you think it'll ever reach something near production equality, or will it "always" be a "toy"?

krichman 14y ago

That's exactly how these OOP languages get translated into C, so the difference would be having a method dispatch table per class or having a global system for multiple dispatch.