value-flavoured approach in API (was: value-flavoured structures)

On 2024-10-05 19:52, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2024-10-04 22:04, Anton Ertl wrote:

[...]

The lack of flexibility of standard TO has not deterred them from
using that.

>
This statement contains the logical fallacy "Survivorship bias" [1].
>
There are different use cases. In some use cases the discussed
flexibility is not needed, in other — it is needed.

 That's a very Forthy way of looking at it.  The usual argument for
getters and setters is that that flexibility might be needed in the
future, so you don't use a mechanism like variables or values that
does not provide this flexibility, in order to avoid having to change
all the places where the variable or value is used, and only have to
change the place where the getter and setter is defined. 

Yes. This becomes even more important for libraries and standard words, because you cannot change code in programs that use the library.

In this
scenario value-flavoured words must not be used unless the flexibility
for TO is provided (i.e., they must not be used in standard Forth).
 But yes, there are probably not many people with that mindset in the
Forth community.

I wonder how many there are :))

Forth-94 seems to have had some of that, though,
with words like GET-CURRENT and SET-CURRENT instead of a (user)
variable CURRENT that had existing practice at the time.  I wish they
had defined GET-BASE and SET-BASE instead of BASE.

Me too. Same for "STATE".
Probably too many programs were already using the "BASE" and "STATE" variables in 1993. However, it was possible to discourage their use and provide a better interface for new programs.
--
Ruvim