Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!mrsvr.UUCP!pet16.uucp!hallett
From: hallett@pet16.uucp (Jeff Hallett x5163	)
Newsgroups: comp.object
Subject: Re: OOP in C
Message-ID: <1691@mrsvr.UUCP>
Date: 8 Dec 89 14:59:40 GMT
References: <3356@hydra.Helsinki.FI>
Sender: news@mrsvr.UUCP
Reply-To: hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163)
Organization: GE Medical Systems, Milwaukee,  WI
Lines: 68

In article <3356@hydra.Helsinki.FI> jokiniem@cs.Helsinki.FI (Jari Jokiniemi) writes:
>
>
>There has been some discussion that one can use object oriented programming
>techiques even when writing the programm with any conventional language. Since
>the concept of what these OOP techniques really are in practise is not well
>explained in any book we've found, the very idea of OOP has remained
>fuzzy for us. 

Since  object-oriented  anything is really  a paradigm,  it should  be
usable  despite   implementation.  However,    certain  implementation
platforms lend themselves to some paradigms better than others.

You can, of course, apply  object-oriented analysis and design to your
system, but  when it comes to  actual implementation, you  will not be
able  to achieve  a pure object-oriented   environment unless everyone
agrees to play by the rules.

It turns out  that just "packaging" your data  structures according to
the standard abstractions (the  linked list is a  classic  example) is
insufficient.   Part  of my   Master's  thesis   was  the design   and
implementation of an  "object-oriented" "language" that was compilable
under  any UNIX-compatible  C compiler (and  would  even compile under
ANSI-compatible compilers).    I quote  "object-oriented"  because  it
didn't have all  the nicities (it did  have dynamic binding of methods
and inheritance at the leaf level, single inheritance, messaging (in a
crude sense) and anonymous creation during loading and storing (a sort
of continuation mechanism, but not a great  one)).  I quote "language"
because it was  really a set of conventions  and predefined structures
and macros that could be compiled under cc.

It  wasn't  great, but   it  did allow  us to write  some fairly large
object-oriented systems using standard  C  compilers with only minimal
difficulty. 

The basic ideas follow:

All instance  variables  and messages are  declared in a  .class file.
Messages are really pointers to functions, as you might expect.

Inside  the class's .c  file, the class struct  is   declared by first
including the superclass' .class file and then its own.  This provides
a simple single inheritance.

The create methods  were recursive - first the  superclass' create  is
called (to initialize  instance variables declared by  the superclass)
and then  the create  codes  specific to this   class is  added.  free
methods were similar.   The  message  slots are filled  with  function
pointers during the create routine - a class may override a superclass
method by simply replacing the  function pointer.  Of course, function
pointers  may be reassigned  at  any time, as   reuqired by the  state
activity of an object.



Of  course, this fixes   the inheritance tree  at compile  time.   The
tricks to achieve posing and  simply continuance  formed the basis for
my  thesis which, unfortunately,  I cannot make generally available at
this time (GE CRD currently has a product involving these techniques).


Maybe this helps, maybe it doesn't. :^)

--
	     Jeffrey A. Hallett, PET Software Engineering
      GE Medical Systems, W641, PO Box 414, Milwaukee, WI  53201
	    (414) 548-5163 : EMAIL -  hallett@gemed.ge.com
		  Est natura hominum novitatis avida