Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!apollo.UUCP!mishkin
From: mishkin@apollo.UUCP.UUCP
Newsgroups: comp.sys.apollo
Subject: Re: So what's wrong with Aegis?
Message-ID: <8706051328.AA23649@apollo.UUCP>
Date: Fri, 5-Jun-87 09:16:34 EDT
Article-I.D.: apollo.8706051328.AA23649
Posted: Fri Jun  5 09:16:34 1987
Date-Received: Sat, 6-Jun-87 10:03:02 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 48


    Most of what David Krowitz points out is true.  I must disagree,
    however, on one point: the naming scheme for function calls.  I
    find the inclusion of a $ in names quite obnoxious.  This serves
    only to maintain the largely artificial difference between system
    (kernel) calls and library function calls.                    
     
You've mistaken what's going on here.  Kernel calls and library calls
are named exactly the same way.  "gpr_$init" happens to be a procedure
in a user space global library; "proc2_$get_info" happens to be a procedure
in the kernel (i.e. an SVC).  Names can be interpreted as one of:

        <manager name>$<operation name>
        <interface name>$<operation name>

By "manager", I mean a particular (non-generic) piece of code that
implements a particular piece of functionality.  By "interface", I mean
something more generic -- an interface might be implemented by a number
of different managers.  For example, the "ios_" interface is implemented
by both the managers for "uasc" type objects and "case" (source history
file) type objects.

Note that all manager and interface names chosen by Apollo end with "_"
to keep them from conflicting with names chosen by customers.  (I.e.
if you're writing your own code using our conventions, you names should
look like "foo$do_this".)

Of course, we can't do anything about the names of standard Unix library
and system calls.  DOMAIN/IX uses the standard names for those.

    The naming scheme, while resulting in descriptive function names,
    also results in function names that are too long and too similiar
    to each other.  When I quickly scan down a section of code, a series
    of function calls beginning with the same words are easily confused.

Of course, this is a matter of esthetics, but personally I'd rather have
it our way.  First of all, it minimizes name conflicts while still allowing
people to use "good names" (e.g. "open") instead of creating funny variants
of the good names.  Second, I find it useful in looking at a piece of
code to know what subroutines calls are likely to be related.  I think
that as the set of library and system calls on Unix grew (esp. in 4.2),
it became very hard to keep track of things (and also, they used up more
good names).

                -- Nat Mishkin
                   Apollo Computer Inc.

-------