Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.programming
Subject: Re: Two object oriented methods, which is better?
Date: Thu, 18 Sep 2014 19:24:13 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 63
Message-ID: <20140918115941.364@kylheku.com>
References: <lvf8uf$o09$2@speranza.aioe.org>
NNTP-Posting-Host: X+c6YNb3AaWMPA3YfA4opg.user.speranza.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.programming:4797

On 2014-09-18, Victor Porton <porton@narod.ru> wrote:
> [Sorry for multiple postings, but traffic of comp.object is so low (as I 
> found after my posting there), that almost nobody will suffer of my multiple 
> posting.]
>
> If I want to push a specific (for a given subclass) value into an array 
> argument of a method, should I just pass the value of the argument to a 
> method which would modify it, or should I create a method which just 
> returns 
> the list of additional values (and use it in the first mentioned method)?
>
> Pseudocode (with "#" starting comments) for a method f:
>
> # modify_array is a dynamic method
> function f(object, array) {
>   object->modify_array(array);
> }
>
> or
>
> # common_array_members is a dynamic method
> function f(object, array) {
>   array = concat(array, object->common_array_members());
> }
>
> What is more object oriented? Which is better?

The second is more functional since it avoids destructively manpulating the
array object. (It assigns to a local variable, but that is a secondary concern
and removable.)

The second approach might be seen as less OO, because the responsibility for
the "modify_array" logic is in a non-OO function. The implementation of object
can only vary what it returns out of common_array_members, but has no say in
what modification is done with it.

However, that is just a perspective. We don't have to divide the world
into "regular function" and "OO function". If we regard f to be an OO
function, then this goes away.

We have a functional abstraction f(obj, array), which does something
appropriate based on the type of obj.  The fact that f is a wrapper
which invokes methods and performs some of the logic is immaterial to the
caller. When the object framework grows more complicatd, the logic
which is done in f can be moved into a method, so that f becomes
a pure method wrapper.

This kind of thing is epecially of no concern in a language which doesn't
stupidly use different syntax for calling OO methods and regular functions;
f(obj, a) could start out being a regular function, and later be upgraded to an
OO method if necessary. The programmer doesn't have to scan the program
for f(x,y) syntax and convert to x.f(y); f(x,y) is the object-oriented call.

Also the functional aspect and OO aspect are orthogonal, because you can
have this:

 function f(object, array) {
   local new_array = object->generate_array(array); # do not modify
   ...
 }

The responsibility for how the objectg and array are combined rests in
the method, and clobbering the array is avoided.