Re: (shorter and new) programming by extension

[Samuel Mize <smize@imagin.net>]

Mike Silva <mjsilva@jps.net> wrote:
> 
> Samuel Mize wrote in message <7b49mm$t7q@news1.newsguy.com>...
>>I'm too pedantic to leave adequate-enough alone, so I've refined my
>>example of non-object-oriented programming by extension.  I integrated
>>that into the text I wrote on that earlier.  I hope somebody out there
>>finds this of interest.
> 
> 
> Thank you very much for your explanations, Sam.  I gather (though I haven't
> read your last message through yet) that programming by extension is
> essentially the mechanics part of OOP, without the data and methods
> organization part (which I gather is best expressed in Ada using the package
> concept).  I hope I've got that right, since I feel like I've had a major
> "oh yeah!" breakthrough.


Well, your new insight is probably pointed in the right direction,
but I can't agree with your phrasing.  For an initial insight, though,
you're doing very well.

> programming by extension is
> essentially the mechanics part of OOP, without the data and methods
> organization part

In a larger sense, it's any technology that lets you extend the
capabilities of a system by linking in new code, without having to
go in and recode or recompile the existing stuff to integrate it in.

The specific examples I've show use Ada 95's polymorphic subprograms
to do this.

Polymorphism is one mechanism that goes into OOP.  But it isn't ALL of
the "mechanics part of OOP," and it isn't the only possible approach
to "programming by extension."

For instance, many Lisp environments take an extremely flexible view of
function definition and linkage, and it's normal to build up a program
piecemeal.  Many of the techniques used in that kind of "rapid
prototyping" can be legitimately called "programming by extension."

Object-oriented folks like to say that the three touchstones of OO
methods are: abstraction, encapsulation, and inheritance.  I think
it's fair to say that they are talking about abstraction in terms
of objects; functional abstractions, or data-flow abstractions,
aren't object-oriented.

- The non-object-oriented programming by extension that I demonstrated
  uses a purely functional kind of abstraction.

- It doesn't require any encapsulation of data -- all the records may
  well be publicly visible, and changed arbitrarily by any part of the
  rest of the system.

- While inheritance of functions is used, there is no general inheritance
  of data structures.

So, it fails all three mechanical tests for object-orientation.

Furthermore, there is no attempt to create a hierarchy of classes that
define the essential abstractions that organize the system.  This is
the philosophical heart of object-oriented methods.

> the mechanics part of OOP, without the data and methods
> organization part (which I gather is best expressed in Ada using the package
> concept).

Well, I'd identify two issues here:

- encapsulation (preventing anything but the object's methods from
  operating on its data)

- organization (pulling together all and only the stuff related to the
  class, for clarity)

For any type, not just tagged types, encapsulation is enforced with
the package mechanism, but ONLY if you make the type private.  So
it's really an interaction between typing and packaging.

Organization may use packaging, as well as the ordering of the code,
naming conventions, and so on.

Now, if you want to get a "class" in the style of C++, you will want
to define a package that contains only the tagged type with its
operations and support items (like constants).

But you should be aware that this is only one kind of object-oriented
coding.  Ada supports a number of other paradigms.  Some people will
argue violently, even rudely, that that is a very poor kind of
object-oriented technology.

Because Ada 95 only provides the building blocks, you can do whatever
kind of object-oriented development you want.  And, you can do other
things with those building blocks (like non-object-oriented programming
by extension).

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam