Signatures

Sather - Language Specification
Prev | Chapter 3. Types and Classes | Next

# 3.2. Signatures

    abstract_signature ==>
            abstract_routine_signature | abstract_iter_signature

    abstract_routine_signature ==>
            identifier [ ( routine_argument { , routine_argument } ) ] [ : type_specifier ]

    routine_argument ==>
            routine_mode identifier_list :  type_specifier

    routine_mode ==>
            [ ( out | inout ) ]

    abstract_iter_signature ==>
            iter_name  [ ( iter_argument { , iter_argument } ) ] [ : type_specifier ]

    iter_argument ==>
            iter_mode identifier_list : type_specifier

    iter_mode ==>
            [ ( out | inout | once ) ]

    identifier_list ==>
            identifier { , identifier }

Operations are performed on objects by calling methods on them, which are either routines (See Routine definitions) or iterators (See Iterator definitions). All method arguments have a mode, which is one of: in, out, inout, or once. The signature of a method consists of its name, the modes and types of its arguments, if any, and its return type, if any. Abstract classes specify a set of abstract signatures, an interface without an implementation. Concrete classes specify a set of concrete signatures which do define an implementation.

We say that the method signature f conflicts with g when

1. f and g have the same name and number of arguments,

2. f and g either both return a value or neither does,

3. each argument mode in `f` is the same as the corresponding mode in `g`, or the mode in one is 'in' while the other is 'once',

4. and each argument type in f is neither a subtype nor a supertype of the corresponding argument type in g, unless both are concrete.

This rule for signature conflict defines which methods may be overloaded (See Sather supports routine and iterator overloading. In addition to the name, the number, types, and modes of arguments in a call and whether a return value is used all contribute to the selection of the method. The modal_list portion of a call must supply an expression corresponding to each declared argument of the method. There must exist a method with the specified name such that:). Sather permits overloading based on the number, type and mode of arguments, as well as whether or not a return value is present. However, overloading is not permitted between 'in' and 'once' modes.

We say that the method signature f conforms to g when

1. f and g have the same name and number of arguments,

2. f and g either both return a value or neither does,

3. the mode of each argument is the same (in, out, inout or once),

4. contravariant conformance:

   - for any 'in' or 'once' arguments, the type in `g` is a subtype of the type in f;

   - for any 'inout' arguments, the type in f is the same type as in g;

   - for any 'out' arguments, the type in f is a subtype of the type in g; and

   - if it has one, the return type of f is a subtype of the return type of g

The set of methods that may be called on a type is called the interface of that type. A type interface may not contain conflicting signatures. An interface I_1 conforms to an interface I_2 if for every method `f_2` in `I_2` there is a unique conforming method f_1 in I_1. The basic subtyping rule is: 'The interface of each type must conform to the interfaces of each of its supertypes.' This ensures that calls made on a type can be handled by any of its subtypes.

Prev | Home | Next
Types and Classes | Up | Sather source files