Re: Closures versus objects

At 06:30 PM 2/17/2007 -0800, Steve Dekorte wrote:
>
>I see. How is inheritance handled with these functions, and how is  
>data added to types? Do you end up writing an object system anyways?  
>And introducing the language on language issue again?
>
>- Steve


	Yes, I believe as mentioned elsewhere these are issues.  I wouldn't necessarily argue that one should try to do without an object system, I only argue that closures can be more elegant for doing object-like things than at first it might appear, at least with the right support from the rest of the language.  Or equivalently, that closures can take over more of the functionality / benefits of objects than might be obvious.  But can they provide 100% of the functionality and benefits, including (desired) syntax?  Theoretically, yes, but how far you can go down this path with convenience, efficiency, and idiomatically (that is, without jumping through hoops or using special tricks) will depend on the other limits of the language you're working in.

	Perhaps as mentioned before there should be an OO system shipped with the language, if for no other reason than having a standard defined, even if that standard is built out of closures in standard library code and not built into the language itself.  Though in some languages with closures, going all the way might not be feasible, without introducing OO features to the language natively.  But perhaps in those cases, one could argue that that is a sign that the rest of the language is insufficiently flexible.

	For example, there is no reason in theory one could not dynamically add fields (bindings) to a closure after it is created, or methods, but I'd be willing to bet that not all implementations of closures allow this sort of thing, for efficiency reasons if nothing else.  If you need that in your OO system, you're out of luck.  But that's a limitation of the closure implementation, not the concept.

	(Adding methods dynamically should be easier than fields since a closure function (method) could be defined that itself is a higher-order function that returns new closures (methods) that capture the same environment -- or actually a slight superset enhanced by the additional inner scope of the creating function itself -- as the original closed-over scope.)