Feature: add partial per-property get/set hooks for clean runtime value coercion

[Copilot]

Description

This PR now goes beyond documentation clarifications and adds a first-class runtime coercion API to generated section classes.

• Issue context
  • Keeps the distinction that IDataValidation<TSelf> reports validation errors and does not mutate values.
• New functionality
  • The source generator now emits optional per-property partial hooks:
    • On<Property>Set(ref T value)
    • On<Property>Get(ref T value)
  • On<Property>Set runs inside the generated setter before equality checks, persistence updates, validation, and change notifications, allowing clean value correction/coercion in consumer partial classes.
  • On<Property>Get allows optional read-time value transformation.
• Documentation update
  • Updated docs/wiki/Validation.md to replace the event-subscription workaround with the new partial-hook API for live runtime coercion.
  • Retained lifecycle guidance (IAfterLoad<TSelf>, IBeforeSave<TSelf>) as safety-net normalization for load/save paths.
• Tests added
  • Added focused tests in tests/Dapplo.Ini.Tests/NotifyPropertyChangedTests.cs to verify:
    • coerced values are stored correctly,
    • PropertyChanged behavior remains correct,
    • equality checks use the coerced value to avoid redundant notifications.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update only

Documentation

New features and API additions require documentation updates.
Failing to update the docs is the most common reason PRs are asked to make further changes.

Check all that apply:

• README.md — feature bullet list, table of contents, relevant section(s), and Registry API reference table updated
• docs/wiki/Home.md — new wiki page added to the table (if a new page was created)
• Relevant docs/wiki/*.md page(s) updated (e.g. Loading-Configuration.md, Registry-API.md, Singleton-and-DI.md)
• New docs/wiki/<Feature>.md page created for significant new features
• No documentation changes needed (explain why below)

Tests

• New tests added that cover the change
• All existing tests pass (dotnet test tests/Dapplo.Ini.Tests/)

Checklist

• Code follows the existing style conventions (see existing files for reference)
• XML doc-comments added/updated on all new public API members
• Breaking changes listed in the description above

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Lakritzator]

@copilot That only takes care on the before save / after load, not while running the application. I used to write my own set property, check the value in there and limit / change it if there was an issue with it. Then report it back via a notify change event, so the UI represents the correct value. How would be do this?

[Copilot]

@copilot That only takes care on the before save / after load, not while running the application. I used to write my own set property, check the value in there and limit / change it if there was an is...

Good point — I added a live in-app coercion pattern to the Validation docs: subscribe to INotifyPropertyChanged, clamp in the handler, and write the corrected value back so the UI updates immediately (while still keeping OnAfterLoad/OnBeforeSave as safety nets). Included in commit 87497d2.

[Lakritzator]

@copilot that is a really ugly solution, I do not like that at all. How can we support this in a cleaner way, by providing a real solution. Is it possible to have the library consumer provide the a set (and probably get?) in a partial class, with a clear API to pass the corrected value to the framework?

[Copilot]

@copilot that is a really ugly solution, I do not like that at all. How can we support this in a cleaner way, by providing a real solution. Is it possible to have the library consumer provide the a se...

Implemented a first-class solution in 5a4c68c: generated classes now expose partial hooks per property — On<Property>Set(ref T value) (for correction/coercion before equality checks, persistence, validation, and change notifications) and On<Property>Get(ref T value) (optional read transform). This lets consumers implement clean setter/getter logic in partial classes without event-subscription workarounds. Added tests and updated Validation.md with the new API. No UI changes in this PR, so no screenshot is applicable.

[Lakritzator]

@copilot If I understand it correctly, if the OnSet method isn't implemented, the compiler leaves them out? The is no performance impact?

[Copilot]

@copilot If I understand it correctly, if the OnSet method isn't implemented, the compiler leaves them out? The is no performance impact?

Yes — for the generated partial void On<Property>Set/Get(ref T value) hooks, if you don’t implement them, the compiler omits both the partial method declarations and their call sites, so there’s no hook-call overhead. In this implementation (5a4c68c), the setter/getter still use a local __value variable, but that is typically optimized by the JIT and is negligible in practice.