Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Standard File Requesters
Message-ID: <3828@amiga.UUCP>
Date: 12 May 89 20:17:41 GMT
References: <0914.AA0914@amigash> <941@sactoh0.UUCP> <11583@well.UUCP> <UYNn=hy00VsfE2FI4k@andrew.cmu.edu> <1051@quintus.UUCP> <11636@well.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Distribution: na
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 126

In article <11636@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
)| I think a better way to organize these things would be objects
)| (classes).  A program would just create objects and send messages to
)| them.  The methods (messages implementations) would be kept in something
)| much like a library, and each actual instance would keep a pointer to
)| its library.

)This is a neat idea which I've been thinking about for a while now.
)There are several problems, technical and social.  The technical problems
)revolve around selecting a message-passing scheme.  My first thought
)was to use the library structure itself as a dipatch table to 
)enumerated methods.  This is very fast since all "messages" are really
)just library calls at hard-coded offsets.  It's limited, however, in
)that classes are strictly hierarchical and methods have to be nested.

I don't know what exactly you mean by nested, but the "array of
function pointers" does single inheritance rather nicely: a subclass
starts out with a copy of the array of its superclass, extends
and replaces some entries.  You might want to pass the message
up the inheritance chain, for example when initializing a new object
instance.

)Another approach would be to use symbolic message codes and have each
)"message" to an object involve some sort of string or ID which would
)be searched for by the object and passed on if unrecognized.  This is
)not nearly as fast and is a lot more complex, but it is fully general
)with regards to building subclasses and extending your superclasses. 
)This scheme can be made fast, but at a price of complexity.
)It also has a giant global namespace which I'm not so hot about.

The namespace is the the blessing and the curse.  It's not hard to code
up a system using technique 1, compile and link it as a module.
Use nested include files to define consecutive method IDs and object
data structure, and if you add a method to class A, your makefile makes
sure you recompile all descendants of A.  And all clients of A.

On the other hand, if some classes are implemented in the system, some
by aftermarket class vendors, and even a third source for the application
program, you clearly can't recompile when you add a method to a system class.

So, for a solution to fly as system code, you MUST have a global namespace.
So, once you do that, you're looking up methods in id tables, plus any 
tricks you want to pull.

To suitably manage a global namespace, it helps to have partitions.
A manageable group of people is responsible for uniqueueness within
the partition, and partitions are handed out by a higher authority.

Objective C does this by partitioning on something they call Packages
or Categories or something (I think the name changed between Cox's book
and the NeXT relealse.)

Brad Cox's book, by the way, describes (evangelizes) Objective-C, his
product.  It's sort of the glorified version of lots of "object-oriented
programming in C" articles that you see everywhere.

I can't remember why I thought that might not be so cool.  Oh, yeah,
it means that classes are members of categories or packages based
mainly on what vendor they came from, not what type of function they
perform (or, for example, who their parent class is!).

There is a different precedent around in network address naming.  You
are granted a group of id's from a higher authority.  You may grant
a subset to anyone you choose.

Now,  you only need a mess of include files for every language in the
world that will want to implement or make use of the classes.  And just
because you have unique id's, it doesn't mean you have unique symbol
to assign them to for programming purposes ...

)The social problem is making it catch on.  I suppose if it is
)useful enough people would use it, but for commercial applications ...
)It's actually the social concerns that have me suggest a filereq.
)library.  a) It can be done reasonably quickly. b) It's small and
)unobtrusive -- you don't have to buy a whole philosophy to use it.
)c) It encuurages the gifted "utility" writers to make their own.
)d) If widely used, it shows off the advantage of having your application
)broken up into lots of little cooperating bits.  (Once that idea is
)sold, it's easier to sell a full-blown O-O system.)

I think you hit the nail on the head, as usual, Stu: it's a big machine
to get people to buy off on.  The position I've advocated has been to
make the filerequester interface particularly "thin:" not a lot of customization
and special features, so that when a more comprehensive system implements
a file requester, the callers to the interim system will start getting
the cool one.

There are some other interesting questions in the object/class UI discussion:

    The big issue is language independence.  I don't read the right journals,
    but I am not aware of any system that doesn't bow to a language.  I'll
    be interested in seeing how they implement classes in other languages on
    the NeXT box.  But on the Amiga, clearly a system needs to support
    the arbitrary reasonable programming language.

    Composition of objects into groups is important.  How do you arrange
    for an up arrow button tell a slider to click up one page?  I've done
    it a couple of ways, but I think I missed out on the Smalltalk style
    Model-View-Controller business.  Gotta get the right journals from
    now on ...   (No, you don't send a REXX message ...)

    How do you "reach into" a composite object to establish a parameter for
    one of its sub-components?

    What kind of user-interface object layout/placement machine do you want?

    After you get to a certain high level, your views on inheritance can change.
    While I was perfectly happy defining a class ScrollSliderWithButtons as
    a subclass of ScrollSlider (no, I don't use names like that really, and it
    wasn't quite like that ...), you get a little sick of making a subclass
    of windows with ScrollingWindows to have ScrollingWindowsWithExtraButton.

    Making little extensions to large classes is what leads people to such
    odious things as "multiple inheritance."  I figure if I read some more
    of those damn journals, there'd be some alternatives to inheritance
    which still give you polymorphism (the ability to say: "Delete You"
    without knowing to whom).

    Also, here do you want to keep all the .library (or .class) files?

jimm
-- 
Jim Mackraz, I and I Computing	   	"He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm          The bubbles where he breathes."
							- Shriekback
Opinions are my own.  Comments are not to be taken as Commodore official policy.