4 ms·

The quote's from Programming in Scala, I wanted to look up exactly how the apply() sugaring is described by the author of the language. I'm not sure it is by de

The quote's from Programming in Scala, I wanted to look up exactly how the apply() sugaring is described by the author of the language. I'm not sure it is by definition OO, it just looks like operator overloading to me, similar to C++'s operator() or Python's __call__. Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)

chimeracoder 14y ago
> claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects. In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions. > the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me Which probably means that most of this discussion may be irrelevant to your interests too. :-) That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value. But if you really care, let me try and explain the following: > If module-level functions are important to the question I would like to know why. :) Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object. In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type psuedocode: type Object type ScalaFunction extends Object type NonFunctionObject extends Object We can have ChildNode[NoneFunctionObject] and ChildNode[ScalaFunction], but we can't have RootNode[ScalaFunction] - we must have RootNode[NonFunctionObject] Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen. For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.

chimeracoder 14y ago

> claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects. In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions. > the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me Which probably means that most of this discussion may be irrelevant to your interests too. :-) That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value. But if you really care, let me try and explain the following: > If module-level functions are important to the question I would like to know why. :) Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object. In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type psuedocode: type Object type ScalaFunction extends Object type NonFunctionObject extends Object We can have ChildNode[NoneFunctionObject] and ChildNode[ScalaFunction], but we can't have RootNode[ScalaFunction] - we must have RootNode[NonFunctionObject] Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen. For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.