|Do you know where your variables are?|
Re^2: I dislike object-oriented programming in generalby w-ber (Hermit)
|on Oct 18, 2007 at 15:38 UTC||Need Help??|
I deliberately tried to steer away from any particular programming language, but if you received the expression that I'm talking about those three, my apologies. The concerns I have about OOP goes beyond single versus multiple inheritance, static versus "dynamic" typing, calling methods versus sending messages, etc. The point was not to compare programming languages, but to explain why the means of abstraction and combination in pure object-oriented thinking do not appeal to me in general.
I should know, having been a FP fanatic... My "functions are modules" argument doesn't mean first class functions or doesn't even presuppose functional programming. What I mean by "passing modules as arguments" is trying to be a generalization of what you can do in different programming languages. It might be implemented as being able to pass function pointers (C); or function names (ALGOL); or function references (Pascal). It might be implemented as passing closures (e.g. Scheme, Haskell, Perl, and too many languages to list); or passing objects; or doing something exotic.
The point is that you can parameterize what code does as well as which state it starts the computation from ("non-module" parameters such as numbers and strings).
But it's not even a concern for me... To me, a programming language is foremost a notation with which and in which to express ideas, usually algorithms. That we have machines that can use text written in the notation to do something is just a bonus. (Rather nice bonus, I must say.) This stand is partially hypochritical, but I can live with it.
If I am worried about pervasive OO thinking in Perl 6, it's because frequently I don't want to think in terms of objects. There are no "efficiency" worries -- I already know there are efficient implementations for message-passing, delegation, virtual function tables, and what-have-you that goes with implementing these things. Just take a look at C++ or OCaml.
The concept of roles resembles Objective-C protocols, though with being able to define not only which functions the implementing class needs to provide but also some common functions that all classes implementing the role "inherit". However, this would again be a much more useful technique to think about if there was no mandatory link to objects and classes! (That's just me.)
I'll install Moose::Role some rainy day, I promise.