3 ms·

I think it's because you can easily make your own object system in a functional language. Make yourself a function (representing an object) that takes in a par

I think it's because you can easily make your own object system in a functional language. Make yourself a function (representing an object) that takes in a parameter that it uses to dispatch a function contained in it. Return the function, and the user can then call that with their args. And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched). Put all of this together in a nice "class" macro, and bam, you've got objects. Though, yeah, I guess this would be really tedious if your functional language didn't have good macros.

omouse 18y ago
"And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched)." That only works if your functions can maintain state and if they can, well they're basically objects aren't they...
- silentbicycle 18y ago
  Well, strictly speaking, they're closures. There's a lot of overlap between objects and closures, though using one or the other will frame the problem in a slightly different way. See also: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- dangrover 18y ago
  That's my point. You don't need to have a separate special construct for objects, or any kind of support for them, when you have first-class functions. As for state information, you could just put a 'let' inside there with your variables, and call mutators on them from inside the "object"'s functions. Hmm, I think all these Scheme-centric classes I've taken have warped my mind. I should seek therapy.
  - apgwoz 18y ago
    > when you have first-class functions. This isn't enough without the ability to close over the lexical environment. See Python pre 3.0, without the dictionary/list "hacks".

omouse 18y ago

"And you still maintain encapsulation, too, because the returned function may access stuff that was only available inside the containing closure (where it was dispatched)." That only works if your functions can maintain state and if they can, well they're basically objects aren't they...

silentbicycle 18y ago
Well, strictly speaking, they're closures. There's a lot of overlap between objects and closures, though using one or the other will frame the problem in a slightly different way. See also: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
dangrover 18y ago
That's my point. You don't need to have a separate special construct for objects, or any kind of support for them, when you have first-class functions. As for state information, you could just put a 'let' inside there with your variables, and call mutators on them from inside the "object"'s functions. Hmm, I think all these Scheme-centric classes I've taken have warped my mind. I should seek therapy.
- apgwoz 18y ago
  > when you have first-class functions. This isn't enough without the ability to close over the lexical environment. See Python pre 3.0, without the dictionary/list "hacks".