@DATABASE "OOEproject"
@MASTER   "ram:OOEproject.doc"

@NODE MAIN "OOEproject.doc"

                                    @{b}ooep@{ub}

@{"0. Preface" LINK "0.Preface"}
@{"1. Why" LINK "1.Why"}
@{"2. Caveats" LINK "2.Caveats"}
@{"3. Submissions" LINK "3.Submissions"}
@{"4. Implementation" LINK "4.Implementation"}
@{"5. The Plan" LINK "5.The Plan"}
@{"6. Notes from the Authors" LINK "6.Notes from the Authors"}
@{"7. Addresses" LINK "7.Addresses"}
@{"8. Next Steps" LINK "8.Next Steps"}

@ENDNODE
@NODE "0.Preface" "ooep/0. Preface"


        This document explains the goals and current accomplishments
        of the Object Oriented E Project, much of which was started
        by Joseph E. Van Riper III, but loosely maintained by the
        Amiga E Encyclopedia folks in general.

        Those of you who don't like to read any big docs can just
        browse through the hierarchie via the @{" Examples " link EMODULES:oomodules/oodoc/guides/Examples/main} document.

@ENDNODE
@NODE "1.Why" "ooep/1. Why"


        OOEP was started because, as of this writing, the Amiga E
        programming language, while very powerful, lacks a very
        comfortable, easily extensible object library to take
        advantage of its Object Technology features.  So, while you
        may program objects, you aren't getting the full benefits of
        Object Technology.

        So, you have the option of creating your own extensible set
        of objects and whatnot on your own, which will take you a
        certain measure of time, or you can use ours.  Since the
        source code is included, you can fix any bugs you might
        stumble upon, or optimize anything that doesn't work quickly
        enough for you, or otherwise improve the system in some way.
        Or, if you want, you may contribute new objects to extend
        the system.  All of these should be sent to the AEE (Amiga E
        Encyclopedia) folks for approval and submission to the
        greater Amiga E audience.

        With this set of objects, Amiga E can become a more friendly
        environment to work with.

@ENDNODE
@NODE "2.Caveats" "ooep/2. Caveats"


        In building reusable code, and building it to be as
        extensible as this hopes to be, one often finds him/herself
        having to make various tradeoffs.  This almost always takes
        the form of speed vs. memory, although in the case of reuse,
        sometimes it's speed/memory vs. reuse.

        A case in point might be some of the stuff that will be done
        in the 'Numbers' objects.  Both memory and speed will be
        used due to the coersion schemes to convert sets of numbers
        to other sets of numbers.

        Sometimes, you'll find the more classical Amiga E approaches
        to be stronger than anything developed here.  If you need
        speed and efficiency or better use of memory, and these
        modules don't exactly offer it for you, you may have to
        build your objects a little more by scratch (say, perhaps,
        using Amiga E's float numbers rather than our object
        'Float').

        The goals of this project is reuse and extensibility.  We
        attempt to make our objects as efficient and
        memory-conserving as possible, but our primary goal is
        reuse.

        If there are any glaring problems (say, an object simply
        doesn't work properly), we ask you either fix the problem
        yourself and send the AEE team your fix (which will make you
        part of the AEE team <grin>) or make the AEE team aware of
        the problem (many of them are also on the Amiga E mailing
        list).

        You'll note the comments in the code are somewhat lacking.
        We apologize for this.. in the interest of getting this
        coded quickly, we dropped internal documentation.  However,
        this document is intended to explain the attributes and
        methods of each object in the library, so you may find
        your answers here.

@ENDNODE
@NODE "3.Submissions" "ooep/3. Submissions"


        You can submit extensions/corrections to this library
        through the AEE mailing list or the Amiga E mailing list, or
        perhaps by ftp to Aminet dev/e.  Please include an e-mailing
        address that we can contact you by, in case we have some
        problems of some kind with your submission.

        You may as well send your contribution to one of us via snail
        mail but eMail is strongly preferred. Getting in touch is so
        much easier.

        If you want to contribute anything please make sure that it's
        documented. It's very hard to find out how something's working
        just by browsing through the source code. As you can see the
        preferred way is to write autodocs in the modules and to turn
        the autodocs extracted from them into Amigaguide databases.

        Read the @{"Addresses" LINK "7.Adresses"} chapter to know where
        to send what.

@ENDNODE
@NODE "4.Implementation" "ooep/4. Implementation"


        You'll note that this library comes with its own
        subdirectory 'oomodules'.  This subdirectory is an idea of
        Gregor, who started putting his devices objects in it.  From
        this directory, you can find the hierarchy of objects that
        make up this project.  You should put 'oomodules' in your
        emodules: set of directories if you want to use them.. or
        recompile all the codes with your own idea of how things
        should be set up.

        If you make a correction in a higher-level object, all
        objects derived from the corrected object will also need to
        be recompiled.  This is an unfortunate result of the way
        Amiga E handles some of its internal stuff with the modules.
        Therefore, if you make corrections to 'object', EVERYTHING
        would need to be recompiled IN ORDER according to hierarchy.

        We hope to get things right the first time <grin>.

        In the following list, we'll outline each object and its
        methods.  As you click deeper into the guide (or pay
        attention to the numbers preceding the titles in the doc),
        you'll note that the methods from preceding objects are
        automatically applied to the current objects.

        And so, we start with the one object from which all other
        objects are derived....

        @{"object/main" LINK "object/main"}

@ENDNODE
@NODE "5.The Plan" "ooep/5. The Plan"

        There is, believe it or not, a general plan to all this.
        We're attempting to apply as much of the GNU Smalltalk
        structure (with perhaps some additional stuff out of IBM
        Smalltalk) as we can in our designs.  We acknowledge that we
        cannot do things the same exact way (nor would we want to),
        but we are attempting to loosely follow this plan.

        So, VERY roughly, here's a road-map to some of the basic
        objects, and their heirarchy, that we hope to have
        implemented and designed sometime in the future.  Some of
        these have already been at least partially implemented,
        although not many of them.

        Object
         Logic
          Boolean
           Bitwise
          Categorical
         List
          QueueStack
          Bag
          TreeAVL
          Set
           Dictionary
         Sort
          Number
           Integer
           Real
           Fraction
            Complex
            Coordinate
          String
          DateStamp
           Time
            Hour
            Minutes
            Seconds
           Date
            Weekday
            Day
            Month
            Year
         Hook
         Library
          Device
           Stream
            Printer
            Serial
            File
            Console
            StdErr
            Clipboard
            Rexx
           Keyboard
           Timer
           Gameport
           Audio
          ReqTools
          IffParse
          Commodities
          GadTools
          Graphics
          Icon
          Keymap
          Layers
          Translator
          Utility
          Workbench

        You can help!  Point out problems with this heirarchy, build
        some of these objects, make out CRC cards or use-cases to
        get a better idea what we're up against... help this come to
        fruition.  See `Submissions' to get an idea of how to
        contribute.

        BTW: CRC cards might look something like the following:

        -------------+
        CLASS Object |
        =============+================================================
        Attributes:  |
        -------------+

         [none]

        -------------+------------------------------------------------
        Methods:     |
        -------------+
                new
                init
                size
                opts
                select
                error
                name
                end
                halt
                sameAs
                differentFrom
                update

        --------------------------------------------------------------

        They are intended to give an idea what the object is
        supposed to do, and how it's supposed to do it.  They're
        only a tool towards developing the system.

@ENDNODE
@NODE "6.Notes from the Authors" "ooep/6. Notes from the Authors"


        As of this document, only two authors have contributed to this
        project.  Hopefully, more folks will catch on to this, and
        contribute useful objects into this system, perhaps even improving
        this system for everyone's benefit.

        This section of the document is included for special notes
        (perhaps pleas, perhaps other things) from the various
        authors who submit work to this daunting project.  If you're
        adding something to this document, please add your name to
        the list.

        Authors of the ooep:

        @{" Joseph E. 'Trey' van Riper III " link /authors/jevr.guide/main} - This text is more than one year old.
        @{" Gregor Goldbach " link /authors/gg.guide/main}

@ENDNODE
@NODE "7.Addresses" "ooep/7. Addresses"


        There are a number of ways to get in touch with us. First, there
        is the E mailing list. You can subscribe it via writing a mail to
        listserv.bkhouse.cts.com, the subject doesn't matter. Just write
        SUBSCRIBE AmigaE in the body. That's it. To get the rules of this
        mailing list write FAQ AmigaE or HELP AmigaE in the body.

        You may also touch us via the Web-site of the AEE since the OOEP is
        a part of it. The address is

            http://grove.mv.com/amigae/AEE/index.html

        If there are any questions or remarks about objects you can of course
        direct them to the author of that particular module or anybody else
        of us. So here are our email and snail mail addresses.


            Joseph E. van Riper III
            email:
              mu3@vnet.net

            (snail mail unknown)


            Gregor Goldbach
            email:
              Glauschwuffel@amt.comlink.de

            snail mail:
              Grüner Weg 10
              21423 Pattensen
              Germany
@ENDNODE

@NODE "8.Next Steps" "ooep/8. Next Steps"

        For the reasons I, @{" Gregor Goldbach " link /authors/gg.guide/main}, stated elsewhere, the archive
        is not in the state it should be. These are the things that have to
        be done next (discussion wanted):

        - Check documentation (major)

        - Test objects and provide test programs (major)

        - Include introductory texts to OO and the oomodules/hierarchy (major)

        - Work out an exception and return code scheme for all objects (major)

        - Make build file (major)

        - include other objects and object collections (dd_modules, oo
          framework)



        - Localize objects with library/locale/catalogList (minor)

        - Tidy up sources (minor)



        Discussion should take place in the e mailing list. Everyone is
        encouraged to contribute thoughts, opinions and ideas. Modifications
        to the hierarchy are coordinated through the e mailing list.

@ENDNODE
