Modern Naming vs. FiveWin Style

[Otto]

Why we deliberately stick to the FiveWin style
When migrating from FiveWin/Harbour to web technologies, you quickly run into modern naming conventions:
openDeleteModal()
handleConfirm()
cleanupOnClose()
They are “state of the art” — but not automatically state of clarity.
Especially in business software, it becomes clear that:
readability and mental familiarity matter more than fashionable syntax.
Comparison
Modern web conventions
openDeleteModal()
closeDeleteModal()
confirmDelete()
handleAbort()
cleanupOnEscape()
Characteristics:
technically correct
framework-oriented
often generic
meaning only emerges from context
strongly shaped by training data and common patterns
FiveWin style (deliberately chosen)
mdDEL_Open()
mdDEL_Close()
mdDEL_Confirm()
mdDEL_Abort()
mdDEL_Cleanup()
Characteristics:
dialog-oriented rather than event-oriented
clear mental reference to Dlg, ACTIVATE, END
each function describes a user decision
immediately readable — even months later
no context needed to understand the effect
Why the FiveWin style makes sense in a business environment
Domain logic beats technical logic
The user confirms, aborts, or closes — nothing is “handled” or “cleaned up”.
Migration without a mental break
The code feels familiar, even though the platform is new.
Maintainability > elegance
Better clear and predictable than “modern” and in need of explanation.
Dialogs are states, not events
That’s exactly how they were conceived in FiveWin — and that’s exactly how they work on the web as well.
Conclusion
Modern naming is not wrong.
But for business software with a long lifespan, the FiveWin style is often:
more understandable, more stable, and more maintainable.
Not everything that is new is automatically better —
some things are simply more familiar and clearer.

[AiBot]

This is a well-articulated perspective on naming conventions. A few thoughts to add to the discussion:

**Where the FiveWin style shines:**
- **Discoverability**: `mdDEL_*` groups everything related to that dialog alphabetically in any IDE — huge for maintenance
- **Searchability**: Grep for `mdDEL_` and you get the entire dialog surface area instantly
- **Migration fidelity**: Developers moving from FiveWin don't need to mentally map "event handlers" back to "dialog actions"

**Where modern conventions have a point:**
- **Framework integration**: React/Vue/Svelte ecosystems expect `handleX`, `onX` patterns for automatic wiring
- **Testing**: `handleConfirm` maps cleanly to unit test names (`it('handles confirm...')`)
- **Event-driven architectures**: When dialogs are truly event-sourced, "handle" reflects the reality

**Pragmatic middle ground I've seen work:**

```js
// Module: mdDelete.js
export const mdDEL = {
open: () => { /* ... */ },
close: () => { /* ... */ },
confirm: () => { /* ... */ },
abort: () => { /* ... */ },
cleanup: () => { /* ... */ },
};

// Framework adapter layer (React example)
export const useMdDelete = () => ({
onOpen: mdDEL.open,
onClose: mdDEL.close,
onConfirm: mdDEL.confirm,
onAbort: mdDEL.abort,
});
```

Keeps the **domain-oriented core** (FiveWin style) while exposing **framework-friendly hooks** at the boundary. Best of both worlds for migration projects.

---

**Question for you**: Are you currently migrating a FiveWin codebase to a specific web stack (React, Vue, plain JS, mod_harbour + HTML5, etc.)? The adapter approach above works differently depending on the target.

---
Respuesta generada por Inteligencia Artificial usando el modelo nemotron-3-ultra-free via OpenCode Zen. Puede contener errores; por favor verifiquela antes de aplicar.
AI-generated reply using the nemotron-3-ultra-free model via OpenCode Zen. May contain mistakes; please verify before applying.