Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #39731

Re: input/output parameters

From Anton Shepelev <anton.txt@gmail.com>
Newsgroups comp.lang.javascript
Subject Re: input/output parameters
Date 2021-03-21 17:35 +0300
Organization A noiseless patient Spider
Message-ID <20210321173545.545eb9058531187e4dced4bd@gmail.com> (permalink)
References <20210313153232.40fa0c8b0adf07d7e807084d@gmail.com> <20210315002732.dbb3221feb6d3a0c065292cf@gmail.com> <604f92ed$0$13963$e4fe514c@newszilla.xs4all.nl> <20210320155006.f1909610fd93de6c3afec7cb@gmail.com> <1sgc5g57tii460r30erthh6nvp94gu4mab@4ax.com>

Show all headers | View raw


John G Harris about output parameters:

> One disadvantage is that proving that the function does
> what it's supposed to do is more complicated. If there's
> just a returned data structure to check then that is (we
> hope) straightforward. If there are external altered data
> structures to check then the job becomes partly a check of
> the function and partly a check that it's used sensibly.

I don't see how the introduction of output parameters makes
you check the function itself and data structures it has
altered instead of just testing its output. One must
*always* check that any function is used sensibly: is
applied to the right values, its result is store in the
right variable(s). It hardly matters whether the result
comes from the return value of output parameters.

Consider the following examples:

   var i1, i2, i3;
   var o1; makeref("o1");
   var o2; makeref("o2");
   var o3; makeref("o3");
   // ...
   ( {o1, o2, o3} = f1( i1, i2, i3 ) );
   f2( i1, i2, i3, $o1, $o2, $o3 );

where the second one uses my makeref() macro-like function
that wraps a value into a pair of getter/setter closures to
make it behave like a by-reference argument.

Both invocations are equally easy to test, say, by some
function

   check( o1, o2, o3 )
   { /* ... */ }

As to the human reader, local reasoning about both the
invocations is the same.  It becomes somewhat harder,
though, when you pass not scalar variables, but the
properties of an object.  Let us now try to do what you call
alteration of local data structures, first my way:

   function makeref(v, n)
   {   return `var ${n} = {set _(val){${v}=val;},get _() {return ${v};}}`;  }

   function func1( $1, $2 )
   {   $1._ += 1;
       $2._ += 2;
   }

   function func2( v1, v2 )
   {   return [ v1 + 1, v2 + 2 ];  }

   var obj = {f1:0, f2:0};
   eval( makeref("obj.f1", "$1") );
   eval( makeref("obj.f2", "$2") );

   func1( $1, $2 );
   console.log(`${obj.f1} ${obj.f2}`);

Althouth the invocation of func1() now changes local
structures, it is still perfectly transparent because the
reader can see the passing of the individual properties as
"output" parameters.

With multiple assignments it would look like this:

   function func2( v1, v2 )
   {   return [ v1 + 1, v2 + 2 ];  }

   ({obj.f1, obj.f2} = func1( $1, $2 ););

but destructuring does not work with object properties,
which is why it is not called multiple assignment (I guess).

A third way to modify local data structures is by passing
them to the function wholesale:

   function func3( o )
   {   o.f1 += 1;
       o.f2 += 2;
   }
   /* ... */
   func3(obj);

Now we have introduced a level of non-transparency, where
the reader of invocation cannot tell which properties are
going to change and which are not.  Sometimes it is OK, as I
know the intent of the function. But formally, the effect of
the invocation upon the local structures is not evident.

But I must admit that the need to modify several properties
of an object in a single invocation of a function not
specific to that object type is quite rare in well-
structured code. A more ralistic example would be the
modification of a signle property:

   o.f1 = func4();
   // or:
   func4( $o_f4 );

which, again, are equally transparent, or would be if
JavaScirpt had supported output parameters natively.

> Also, building code that runs a confidence test of the
> function becomes more complicated.

What is a confidence test?  All I find in the internet are
psychological quizzes.  Anyway, ease of use should be always
preferred to the ease of testing.  A little wrapper to
invoke the function according to its interface is not a big
deal, if you need automated tests.

> That said, sometimes it can't be avoided : where a file is
> read by several different functions for instance.

What can't be avoided -- managing the state of the file
object?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-13 15:32 +0300
  Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-13 15:16 +0000
    Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 18:51 +0300
      Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 16:15 +0000
        Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-14 18:31 +0000
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 22:27 +0300
            Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:44 +0000
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:41 -0700
        Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 22:17 +0300
          Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:28 +0000
          Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:39 -0700
      Re: input/output parameters Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-03-14 22:32 +0000
      Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:36 -0700
        Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 14:49 +0300
          Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 11:59 -0700
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 13:07 -0700
          Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-20 19:29 +0000
            Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-20 20:35 +0000
  Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-15 00:27 +0300
    Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:51 +0000
      Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 14:56 +0300
        Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-20 15:08 +0000
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 15:16 +0300
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-21 08:46 -0700
              Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-04-10 14:54 +0300
        Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 12:05 -0700
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 15:58 +0300
    Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:43 -0700
    Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-15 18:01 +0100
      Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-16 18:06 +0000
        Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-16 23:58 +0100
          Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-17 19:14 +0000
            Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-17 23:46 +0100
              Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-18 18:04 +0000
                Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-22 00:39 +0100
                Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-23 10:44 +0000
                Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-30 00:33 +0200
                Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-31 19:53 +0100
                Re: input/output parameters Silvio <silvio@internet.com> - 2021-04-01 01:17 +0200
                Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-01 18:02 +0100
      Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 15:50 +0300
        Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-20 18:52 +0000
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 17:35 +0300
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-21 08:50 -0700
              Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 19:31 +0300
            Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-21 19:27 +0000
        Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 13:02 -0700
  Re: input/output parameters Postiljon Petskin <yyyyyyyyyyyywwwww@zohomail.eu> - 2023-04-22 08:47 -0700

csiph-web