FiveTech Support Forums

Hello friends,

I’m currently working on several Harbour/web projects (microservices, DBF tools, HTML engines) and I’ve been experimenting again with a more procedural, preprocessor-driven approach – intentionally without classes or OOP hierarchies.

The starting question is:

Do we really need OOP in the xBase/Harbour world – or is a modular preprocessor approach with global state actually more suitable?

My setup uses:

global module-level state variables (e.g. G_CONFIG, G_DB, G_FORM)

a preprocessor/patcher (similar to a “Harbourino” concept) that injects blocks such as -> HEADER, -> TABLE, -> FOOTER directly into the source code

modules that behave like composable building blocks, similar to modern web frameworks (Svelte, Astro, Go templates)

Observed advantages

far less overhead compared to OOP

debugging is easier because the real source code remains visible

modular structure via blocks rather than classes

very low complexity

extremely well suited for DBF/microservice workflows

clean and transparent for web-oriented template logic

Possible drawbacks

global state requires naming discipline

in larger projects things can become harder to track

dependencies may become “implicit” instead of explicit

no classic encapsulation model like in OOP

My question to you:

How do you see this in the Harbour ecosystem?

Are we using OOP simply because it “sounds modern”, even though most xBase-style applications (DBF, web templates, microservices, tools) are inherently data-driven and procedural?

Or are there concrete situations where OOP in Harbour is truly indispensable?

I’d appreciate any insights — especially practical examples where OOP shines or where a procedural + preprocessor approach turns out to be more elegant.

Best regards, Otto

Dear Otto,

OOP is the way to avoid spaghetti code :)

I can't imagine a FWH without classes...

Like everything else, OOP has to be used when it is really helpful. I agree with Antonio: FWH can't be imagined withou classes. FWH manages objects inherently. Any object instance needs to be represented by a set of state values. It would be really hard to write FWH without objects, definitely. But you don't need OOP for everything. Normal procedural functions have not to be replaced by classes.

Dear Antonio, dear Enrico, The term spaghetti code is a strong framing that quickly adds an emotional tone to a discussion. I’d like to look at this from a technical angle, without such frames — because my approach is structured, just organized differently.

Thank you both for your replies — and yes, I think Enrico’s point reflects very well what I meant.

For a library or a framework with a large user base, OOP absolutely makes sense. You need clear structures, contracts, and long-term maintainability — otherwise things get chaotic.

But for our own projects, especially now in a time where we increasingly work with AI support, I’m not sure that heavy OOP layers are always the best path.

In web development, additional class and abstraction layers can reduce the direct debug transparency we get from browser tools like F12. Since debugging in Harbour is not particularly easy to begin with, this can have a noticeable impact. Also, AI tools tend to handle flat, modular structures more effectively than deep OOP hierarchies.

Best regards, Otto

Dear Otto,

IMO spaghetti code, vibe coding, etc. are commonly used terms in coding with no emotional tone at all.

If you use many variables, all together, you can't know which variables belong to what. Using objects, each object contains its variables (DATAs). Same applies for functions. Methods group functions with variables (DATAs).

We are not forced to use OOP in all circunstances if the app is not very complex. Once you reach a certain level of complexity, the code itself "asks" for objects to get clearity and modularity.

We can not confuse developers telling them that procedural coding is as good as OOP. This is not true. For small and simple apps, procedural coding is ok. When the app gets more complex, OOP is a must.

There are no good alternatives to store (as an example) the coordinates of a Windows control other than using an object. And, on the contrary, an object is useless if you are writing code that just makes a single task, then terminates.

Dear Antonio, dear Enrico,

thank you both for your explanations. May I add a question from a web-development perspective, because this is the environment in which we use mod_harbour and HIX today?

OOP is a great model for UI frameworks where objects really “live” and keep state (dialogs, controls, events). But modern web systems are increasingly stateless: a request comes in, some logic runs, a response goes out. Nothing remains in memory.

Because of this stateless environment, many modern platforms (for example Node.js) do not rely on classical OOP at all. They use modules, functions and small composable units instead of deep object hierarchies — and they still handle enormous complexity and scalability.

So my question is simply:

How do platforms like Node.js achieve large, maintainable architectures without traditional OOP, and could these ideas also apply to Harbour’s web-related workflows?

I’m asking this out of genuine curiosity, because in the web context the trend seems very clearly away from heavy OOP and towards flat, modular, stateless designs.

Best regards, Otto

Dear Otto,

If the code uses hashes and codeblocks only we may say it is not pure OOP but somehow it is OOP alike designed.

Gemini's answer to this statement:

You have hit the nail on the head. You have intuitively discovered a concept that Computer Science calls Prototype-Based Programming (or Object-Based Programming).

It is OOP, but it is Classless OOP.

In classical OOP (Java, C++, Harbour Classes), you need a blueprint (Class) to build a house (Object). In this "Hash + Codeblock" style, you don't need a blueprint. You just build the house directly by gluing parts together.

Here is why your observation is so accurate, and why this specific "flavor" of OOP is dominant in modern web development (JavaScript, Lua, Python dicts).

It is not impossible to write complex software without OOP. Even Windows has been written without OOP. It is only much more difficult to write and maintain. In a stateless environment, probably you will not need OOP.

Dear Antonio, dear Enrico,

your comments about classless / prototype-based OOP match quite closely what I tried to describe in my earlier post.
For my own work, the patcher + preprocessor approach has proven very productive, especially in stateless web scenarios where modular units and clear structures are more important than deep class hierarchies.

At the moment, my toolchain is still very personal — mainly built around VS Code, TotalCommander, and a FiveWin management tool that is maybe 95% finished. I know its quirks, so it works well for me, but another developer would probably need better tooling and documentation.

So the concept works, and it aligns well with modern AI-driven and Node.js-style development — but it would need more polished tools if used in a broader context.

Best regards,
Otto

PS:
By the way, for anyone interested in the background of this discussion, I once wrote two posts that are actually very close to what Antonio’s “classless / prototype-based OOP” statement describes today:

1. “Harbourino – The ‘Too Simple’ Idea That Outlived the Frameworks”
   A comparison of heavy OOP-based frameworks versus a declarative, FiveWin-style preprocessor approach.
   Core idea: clarity, modularity, no runtime overhead, AI-friendly, very close to modern web component thinking.

https://forums.fivetechsupport.com/viewtopic.php?p=279973#p279973

1. “Advantages of a Patcher and Preprocessor over OOP”
   A list of benefits such as zero runtime overhead, better debugging (original source), dynamic code generation, faster development cycles, and easier integration in stateless web projects.

https://forums.fivetechsupport.com/viewtopic.php?p=272012#p272012

Both posts describe the same concept we are now discussing here — and from today’s perspective they align surprisingly well with the prototype-based, classless OOP that is common in Node.js and modern web development.

Maybe it could be interesting to revisit them in this new context.

Hi,

Anyone who can code with OOP can also code procedurally. And pretty much everyone who can do this knows when it's better to use a simple function versus a class.

To respond to your comments, I don't think those of us who do web programming use deep inheritance hierarchies. Using these classes doesn't overload the system, and using classes has nothing to do with whether you're in a stateless environment.

You can't just go around passionately telling other users that using classes for web development is wrong. If you like and you're comfortable with your way of coding, then that's fine, but please stop confusing people.

If we're in a Harbour forum, why should we look for solutions in Node, PHP, or others? Can you do it? Of course, but what's the point?

If you post code or pseudo-code here, we can discuss different ways to build it, but stating that one way is better (or more advisable) and the other isn't - sorry, but I disagree.

By the way, we're debating on a forum that was built using classes…

Wishing you a happy Sunday...

C.

Before diving into OOP, procedural code or architectural styles, I think the biggest challenge we face in our move towards web development is something much simpler:
we still don’t have a shared, practical hardware infrastructure model.

Without this foundation, any discussion about classes, preprocessors or design philosophies becomes secondary.

In practice, there are only two realistic ways to run Harbour-based web applications:

1. Self-hosting

(often preferred in Europe due to GDPR/DSGVO)
Two secure exposure methods:
• own firewall / port forwarding
• Cloudflare Tunnel / Connector (no open ports, automatic HTTPS)

1. External hosting (VPS)

A rented server with full root access for Apache, Harbour modules and custom components.

For many use cases, the Cloudflare Connector is currently the most practical option — secure, simple and very compatible with Harbour workflows.

It might help all of us if we start collecting experiences and best practices around these two setups, so newcomers and experienced users can rely on a clear, safe and unified way to host Harbour-based web applications.

Dear Carles,

before going into technical details, I want to clarify one thing: several different frames entered the discussion, although none of them reflect my intention:

Competence framing: OOP vs. procedural developers

Safety framing: classes as the “safe/default way”

Confusion framing: procedural/declarative code “confuses people”

Context framing: looking at Node.js means “leaving Harbour”

Authority framing: referencing older systems as proof of correctness

My goal is simply to understand which abstraction fits the nature of the web, not to promote or attack any paradigm.

I am not saying that using classes is wrong.
I am questioning the assumption that classes must be the default way to structure web logic.
The web is fundamentally stateless, declarative and HTML/JS-driven, which is very different from a stateful desktop GUI.

In this context, using examples like Node.js, ASP-style preprocessing or modern build-time tools is not “leaving Harbour” — it is simply acknowledging how the web platform itself works today.

Once we remove the framing, the real technical questions become clear:

When does OOP help in a web environment?

When is a declarative or build-time approach more natural?

Where do wrapping layers add clarity — and where do they add complexity?

That is all I wanted to explore.

Best regards,
Otto