 |
lua-l archive |
|
|
||
|
Alex Queiroz wrote:
It's amusing that you call "that parameter/argument syntax" a
"leftover mindset" of "traditional function-oriented languages". So OO
must have won, then. Should I stop programming in Haskell now and
learn Java?
Sorry, I didn't mean to suggest that OO is better than functional or procedural or logic programming, etc. In fact, I'm an avid OO critic (and Java, C++ critic). The OO paradigm is near the bottom of my list.
I avidly prefer Lua's prototype approach to objects, and the "method by association" approach, as well as Lua's powerful use of tables as the fundamental construct. -- Give me a Lua lever long enough and I can move the world!
In my earlier post, however, I used the term "function oriented" to make a distinction from "functional", that obviously wasn't so distinct. What I really meant about "leftover mindset" was that C++ and Obj-C were originally defined as pre-processor extensions to C, a "function oriented" (thought not "functional") programming language.
Specifically, when Bjarne Sroustrap and Brad Cox originally implemented "self" semantics in C++ & Obj-C, they were limited to how they could accomplish that with pre-processor constructs. And that meant that they didn't originally have free access to C-language implementation details, like controlling the internal structure of the call frame. So any pre-processor implementation of self had to just glom a hidden parameter into function definitions and an extra argument into function calls.
That C++ / Obj-C "hidden argument" pattern for "self" (or "this") is the vestige ("leftover mindset") to which I was referring. I did not intend to make a judgment about the merits of functional or procedural or object-oriented programming.
What I was suggesting, though, is that the colon operator in Lua is a by product of making the same "hidden argument" implementation choice that was used in the original pre-processor constrained C++ & Obj-C implementations. -- And that the "hidden argument" pattern could be avoided by accessing caller context and identity that is found elsewhere in the call frame (i.e. and not in the stack of proper arguments).
// Brian