🚀 go-pugleaf

In article <slrn4l9gov.2hg.crawford@kloognome.cris.com>,
Robert Crawford <crawford@iac.net> wrote:
>Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:
>>If you are a master in this paradigm, OO doesn't strike you as anything ``Zen
>>like'', but as a marginal improvement in some aspects of design  and
>>implementation that's generally not worth the hassle. You can benefit from 
>>OO approaches even ifyou use languages like C and Modula 2. You don't need the
>>extra linguistic frills to benefit from the useful concepts of the paradigm.
>
>	Let me add that I've seen this done -- I'm working on a
>project that incorporated a lot of features that look, act, and read
>like objects. They just happen to be written in plain C.

I do the same thing. I once switched to Modula 2 and later back to C. I found
no problems bringing in concepts from modula 2, except for visibility
operators: the ability to reference an object using module_name.member_name, or
optionally to import the member explicitly and then dispense with the extra
qualifier.

I once wrote an assembly language module which completely conformed to the
Modula 2 conventions. I hacked the compiler's object format, and named my
assembler symbols so that they behaved just like Modula 2 objects with respect
to the module.member name space convention.

I made an interface specification in the DEF file, and everything worked
properly: abstract data typing with assembly language. The same could be done
with OO.

>	We didn't have a C++ compiler, and we only had 3.5 trained C
>programmers, let alone anyone with enough experience in C++ to carry
>everyone else.

Which shows that all kinds of factors are involved in language choice, not just
techno-weenie justifications.
--