On Tue, 05 Jan 2021 20:20:27 +0000, gareth evans wrote:

> On 05/01/2021 20:12, Charlie Gibbs wrote:
>> On 2021-01-05, Martin Gregorie  wrote:
>>
>>> On Tue, 05 Jan 2021 15:30:06 +0000, gareth evans wrote:
>>>
>>>> That it warrants such an involved explanation is very good reason why
>>>> such techniques should be avoided today!  :-)
>>>
>>> Agreed.
>>>
>>> That sort of thing is so much easier in Java or Algol 68, which both
>>> recognise that methods/procedures with the same name but different
>>> parameter lists are indeed different pieces of code rather than a
>>> stupid mistake.
>>
>> I avoid that technique - it invites other stupid mistakes.
>>
>>
> +1
>
> Why any coder would want a procname with different calling lists is
> beyond me.
>
> To object to having x_procname and y_procname etc suggests a coder is
> not focussed on the matter in hand but is religiously adhering to some
> irrelevant convention.

Its very useful indeed in Java: its often helpful to use the same name
with different parameter lists for constructors and also for methods that
all do similar jobs, e.g for outputting values from a class its helpful
to use the same method name,  with different parameter lists say:

getValue(String caption, int value);
getValue(String caption, double value);
getValue(String caption, boolean value);

where inventing a set of different method names adds little clarity to
the code and about the only likely mistake is to try to use it with an
unsupported type of value - which will cause a compilation error as you
might expect.

Similarly, the ability to something similar in Algol 68, is equally
convenient ana, IME anyway, doesn't make the code any more error prone or
less readable.

In both languages, context selects the appropriate method or proc and
using an undefined variation gets you a compilation error, despite Algol
68's tendency to widen numeric values to fit a parameter definition.


--
--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05