[Coco] OO programming - [Was]:Emulator

[Mark McDougall]

Fedor Steeman wrote:

> Boy, I sure saw that one coming! :-)

Heh, and I'm sure this discussion has the potential to spiral out of control 
and run for weeks if we allow it. But I'd at least like to respond to a few 
points at the risk of annoying others...

FWIW I don't think we're ever going to agree or convince one another... ;)

> Well, for one thing OO/D&P helps the programmer focus on the problem
> domain, rather than on trivial hardware or platform-related requirements
> that in our day and age are or should be abstracted away anyways. 

That may be true if there is an appropriate framework already in place that 
is applicable to the problem domain. In the case of a coco emulator, the 
host GUI would be a good (and perhaps only) example.

> long run, it will help the body of code remain easier to overview, easier
> to understand, easier to develop, easier to manage and easier to change
> and expand, especially when applying well-established Design Patterns.

Only if well-written, and only if the OO paradigm is applicable to the 
problem. OO is not a magic bullet - it is not _automatically_ easier.

> Perhaps so, but I can see major advantages in abstracting away logic
> dealing with display and I/O and at the same time implementing the
> emulated system's machine logic as the signal-exchanging objects that
> they in reality are. 

You touch on the host GUI as I suspected and yes, depending on the host OS 
and cross-platform goals that may be true. But I suspect that the 
implementation of the coco logic may not benefit as much as you hope from OO 
design. For a single-target emulation, you're probably going to spend a 
_lot_ more time architecting and implementing the framework to support your 
ideal design, negating any benefits and in fact complicating the software.

The major benefits in OO design include re-use, loose coupling and 
maintainability - important benefits on large systems with many different 
components interacting and being used simultaneously by several other system 
components. Here abstraction is a huge plus, being able to hide 
implementation details behind a stable and well-known interface as the 
system grows and functionality is added.

I don't really see where any of this is much use to a coco emulator. And of 
course it comes with a cost - increased development effort (code size) and 
decreased performance (as you concede).

> A poor craftsman blames his tools. Or: bad craftsmanship is more easily 
> blamed on the craftsman than on his tools. So that argument is not really
>  valid. :-)

I didn't blame OO at all. My point was that a bad OO program is just as bad 
- if not worse - than a bad procedural program. And I've seen both, trust 
me. So your assessment of my "argument" is not really valid! :-)

> Thanks, I will take your encouragement to heart and hope that I (or
> someone else) some day will be able to come up with something new and
> exciting for the community! Whatever it may be and however it may have
> been developed! :-)

At the end of the day, it doesn't _really_ matter what tools are used, as 
long as they are used properly. And of course, everyone has a toolset with 
which they are more productive and skilled. Myself, I've worked on PC 
business applications in C++, through device drivers in C, down to coding 
assembler on micros and soft-core processors in FPGAs. I try to choose the 
most appropriate tools for the job at hand - though I must admit that C is 
always my fall-back language of choice for a lot of quick-n-dirty jobs that 
perhaps other languages (perl, sed/awk) would be more appropriate.

That said, personally, I probably wouldn't choose to do an OO Coco emulator.

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"