[dangrover]

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]

"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...

[dangrover]

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]

> 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".

[silentbicycle]

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/m...