[CuiweiG]

Closes #6582.

The ?ggproto example assigned to a field inside a method (self$x <- self$x + n), which is the pattern extension authors should avoid. This keeps the Adder/Doubler example, but add() now only reads self$x. Doubler overrides x, so the example also shows that self is still the child when the parent's method is called through ggproto_parent() (Doubler$add(10) gives 25).

The "Working with ggproto classes" section gets one extra sentence: reading fields through self is fine, assigning to them is discouraged.

[teunbrand]

Thanks for preparing a PR!
I think the proposed change is not exactly what we want users to learn about ggproto classes. It may have very well be my insufficient explanation in #6582 that had set this on the wrong track.
To explain a bit more; it is fine to read from a ggproto object's fields, but to write to that field is discouraged.
In the old example, self$x <- self$x + n is the problematic piece.

[CuiweiG]

Thanks for the clarification — the write-vs-read distinction wasn't clear to me from the issue alone. Will revise the example to keep the field-based inheritance pattern but drop the mutation. Back to you shortly.

[CuiweiG]

Sorry for the long wait on this one.

Reworked it based on your explanation. The Adder/Doubler example is back, but add() now only reads self$x and doesn't assign to it. I also gave Doubler its own x = 5, so Doubler$add(10) returns 25. That way the example shows self is still the child when the parent method is called via ggproto_parent().

I removed the paragraph about stateless classes and added just one sentence under "Working with ggproto classes": reading fields through self is fine, but assigning to them is discouraged. NEWS is updated and I merged in main.

If you'd rather keep Doubler as it was (without overriding x), I can change it back.