@DATABASE "songclass"
@MASTER   "Work:SC/XM/Autodocs/songclass.doc"
@REMARK   This file was created by ADtoHT 2.1 on 08-Apr-97 12:17:15
@REMARK   Do not edit
@REMARK   ADtoHT is © 1993-1995 Christian Stieber

@NODE MAIN "songclass.doc"

                                  @{b}songclass@{ub}

@{"background" LINK "background"}


@ENDNODE
@NODE "background" "songclass/background (information)"


    NAME
        songclass -- XModule 'boopsi'-oriented song implementation.

    DESCRIPTION
        The song class is an object oriented way to handle a song.  The song
        class handles all data storing mechanisms for you and adds a layer
        of abstraction between the song internal data structures and the
        application.  The advantage is that the internal structures can be
        changed while keeping compatibility with existing software.

        Another great advantage of being a 'boopsi' class is that the song
        can notify other boopsi objects whenever its attributes change.
        This simplifies the task of keeping the user interface updated each
        time the user (or an ARexx macro, or whatever) changes something.

        For speed reasons, the song class does also allow 'white box'
        istance access.  This means that you can also directly access
        the internal data structures of the song, without using standard
        boopsi methods.  You are ONLY allowed to READ public fields, but not
        to write any of them.  The main reason to forbid direct writing is
        that the song class must send notifications to its targets, but it
        does also allow the song implementation to change in future version
        without breaking existing applications.

        When you create a new istance of the song class, the object handle
        you get is actually a SongInfo structure.  This is only possible
        because the song class is a subclass of the rootclass, whose istance
        is placed at a negative offset in the object handle.
        Future song class implementations could require to be subclasses
        of other classes, such as the gadget class or even the datatypes
        class.  This problem will be probably got around by keeping the
        root class as the real superclass of the song and creating an
        istance of the other superclass which will be passed all the
        methods which are not recognized by the song its-self.  Call this
        boopsi polymorphism, if you like to :-)

    QUOTATION
        Don't be a tuna head.

@ENDNODE