scalar vs array and program control

[Laura Creighton]

In a message of Sat, 25 Jul 2015 18:53:33 +0200, "Thomas 'PointedEars' Lahn" wr
ites:
>Laura Creighton wrote:
>
>> […] "Thomas 'PointedEars' Lahn" [writes]:
>>> Laura Creighton wrote:
>>>> […]  You really cannot make your code 'more functional' and 'more
>>>> object-oriented' at the same time -- more in one style implies less
>>>> in the other.
>>> How did you get that idea?
>> 
>> Because pure object oriented techniques are best when you have
>> a fixed set of operations on things, and as your code evolves
>> you primarily add new things.  Things written in a functional style
>> work best when you have a fixed set of things, and your code evolves
>> you add new operations for the existing things.
>
>Your logic is flawed.  “*Pure* object oriented” is your raising the bar.

Yes.  But I could have said, and probably should have said 'pure
functional style' as well.

>First of all, object-oriented programming and functional programming are 
>programming *paradigms*, not merely techniques.  Second, they are _not_ 
>mutually exclusive paradigms.  Third, Python supports both because in 
>Python, functions are first-class objects.  (In fact, if I am not mistaken, 
>everything except None is an object in Python.)

Ah, digression here.  I generalise  between paradigms that generate
useful techniques, (functional programming and object oriented programming
both do this) and those that do not (the Marxist paradigm of the
labour theory of value).  It still may be very useful and instructive
to think on the Marxist Labour Theory of value, and it may have new
utility if we can replace all labour with computer/robotic/IT
... but for now, do not run your economy on this theory, ok, because
it does not work.)

Second digression:  that a thing uses objects does not make the thing
more object oriented.

>For example, let us make this original Python code more object-oriented and 
>more functional at the same time:
>
>#------------------------------------------------------------------------
>def foo (a, b):
>    return a + b
>
>print(foo(42, 23))
>#------------------------------------------------------------------------
>
>First, more functional: 
>
>#------------------------------------------------------------------------
>def foo (f, a, b):
>    return f(a, b)
>
>print(foo(lambda a, b: return a + b, 42, 23))
>#------------------------------------------------------------------------
>
>Instead of hard-coding the “+” operation, (a reference to) a function 
>(object) can be passed that is passed the remaining arguments, and the 
>return value of the function is returned instead (you could overload the 
>operator, and the “foo” call here could be inlined, of course; this is just 
>an example).
>Second, more object-oriented:
>
>#------------------------------------------------------------------------
>class A:
>    def __init__ (self, v=0):
>        self._value = v
>
>    def foo (self, f, b):
>        return f(f, self._value, b)
>
>print(A(42).foo(lambda a, b: return a + b, 23)) 
>#------------------------------------------------------------------------
>
>The first operand now is an object, an instance of a class, and the former 
>“foo” function has become a method of that class that the object inherits.  
>The method could be further inherited from a superclass, or overwritten by a 
>subclass, for polymorphism.  The callback could also be a public method 
>provided by a class.
>
>There are probably better examples.  In any case it should be possible for 
>you to see that you are mistaken: One *can* make code more functional and 
>more object-oriented at the same time, and more in one "style" does _not_ 
>imply less in the other.

Okay, I give.  It's possible, and I overstated things.

But I suspect that it is only possible in things that are in
the behavioural middle. You needed a lambda to make the thing more
functional, and to create a class where none was before to make it
more object-oriented.  But this means that the thing wasn't all that
functional nor object-oriented -- most likely procedural -- to start with.

So, very clever.  But still the general rule in refactoring, is that
you want to go more oo or more functional, not both at the same time.

Laura